JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
bug_report_small.png
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
     
    		 Closed
  • Assigned to
    lolo4j
  • Progress
       
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
    zorba128
  • Owned by
    Not owned by anyone
  • Category
    Client
  • Resolution
    RESOLVED
  • Priority
    Normal
  • Reproducability
    Not determined
  • Severity
    Low
  • 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...

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

Fixed in:
#5
Comment posted by
zorba128
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

#6
Comment posted by
lolo4j
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