JPPF Issue Tracker
Please log in to bookmark issues
CLOSED  Bug report JPPF-329  -  Inconsistent classloading in org.jppf.client.balancer.ChannelWrapperRemote
Posted Sep 18, 2014 - updated Aug 15, 2018
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Bug report
  • Status
  • Assigned to
  • Progress
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
  • Owned by
    Not owned by anyone
  • Category
  • Resolution
  • Priority
  • Reproducability
    Not determined
  • Severity
  • Targetted for
    icon_milestones.png JPPF 4.2.x
Issue description
Implementation of org.jppf.client.balancer.ChannelWrapperRemote.getClassLoader should probably be changed to use slightly more generic implementation (as in NodeExecutionManagerImpl). Original implementation used getTaskObject only for JPPFAnnotatedTask making it impossible to provide custom task wrappers.

private ClassLoader getClassLoader(final JPPFJob job) {
      if (job == null) throw new IllegalArgumentException("job is null");
      if (job.getJobTasks().isEmpty()) return null;
      else {
        Task<?> task = job.getJobTasks().get(0);
 Object o = task.getTaskObject();
  return (o == null) ? task.getClass().getClassLoader() : o.getClass().getClassLoader();
Steps to reproduce this issue
Hopefully not really needed...

Comment posted by
Sep 18, 17:29
Ok, thanks for the code review!

Fixed in:
Comment posted by
Sep 19, 07:12
Hi, thanks for fix.

This wasn't code review - I was stuck when trying to wrap code to be executed in the functional way (by passing closure), instead of overriding Task base class. Straightforward way (calling closure from Task-derived wrapper) didn't work due to issue above - the only solution I've found after digging into jppf sources was to use JPPF AnnotatedTask as a base (which I think isn't really meant to be used by client code directly).

It took me quite a while to find out that I can use getTaskObject to control classloading behavior. It seems the sole purpose of that method is just be able to get getTaskObject().getClass().getClassLoader(). In that case it would be much more natural (and self-descriptive), if Task simply had getTaskClassloader() instead, which should default to this.getClass().getClassLoader(), being overriden in AnnotatedTask (and my wrapper...) to use payload's classloader.

regards, Marcin

Comment posted by
icon_reply.pngSep 19, 08:18, in reply to comment #5
You are making an excellent point. I registered this as Feature request JPPF-330 - Add a Task.getTaskClassLoader() method