In addition, it would be great to be able to reset a client class loader (in effect create a new class loader instance) without having to disconnect and reconnect the node.

This would allow a much more flexible class path management, as it would be possible to change or remove elements of the classpath (i.e. new libraries or new versions of existing libraries), on the fly with a minimal impact.

I have refactored the class loader code so now the class loader code is completely separate from its connection to the driver. Committed to trunk revision 2624.

What remains to do is to implement the mechanism that will allow creating a new class loader instance for the same server or client (based on uuid path) "on the fly", before the tasks are desrialized in the node. This will allow to change or remove existing classpath elements without having to disconnect/reconnect to the driver. The classpath will ned to be rebuilt via calls to AbstractJPPFClassLoader.addURL().

Also, we need to make sure that the resource cache in the server is cleared or reset for the given uuidPath, otherwise some class loading requests will never reach the client and be served by the driver directly.

This enhancement is now implemented. Changes committed to SVN trunk revision 2636

The issue was updated with the following change(s):

• This issue has been closed
• The status has been updated, from New to Closed.
• This issue's progression has been updated to 100 percent completed.
• The resolution has been updated, from Not determined to RESOLVED.
• Information about the user working on this issue has been changed, from lolo4j to Not being worked on.