User-defined node class loading

Details the Java™ classes packaging options and loading order precedence for user-defined nodes.

For both packaging mechanisms, if the classloader cannot find a required class within the package it defers to the shared class loader to find the required class. The shared classloader looks in a set of directories on the integration node machine and loads any JAR files found. It can be used to install any required JAR files that do not need to be repeatedly deployed, such as client libraries that the Java compute nodes need to use. For more details, see Java shared classloader.

If the required class cannot be found in any of the deployed JAR files, or in the JAR files installed in the shared classes directories, a classloader containing all of the integration node supplied classes is checked (for example: this classloader contains the jplugin2.jar), followed by the classpath, and then finally the Java virtual machine (JVM) system classloader.

Two key points must be considered when deciding which of the above mechanisms are used to load a class:

• Isolation between different applications (for example: adding classes to the classpath makes them available to every part of IBM Integration Bus and can cause conflicts).
• Delegation from one classloader to another can only occur in one direction. If a class is resolved in the shared classloader, then it cannot directly create classes in the PAR classloader.