See information about the latest product version
JavaCompute node classloading
Details the default Java™ classloader options and the precedence order of each type.
The JavaCompute node loads and runs a Java class defined as the Java class property on the node. Normally, this class is deployed, along with any other required classes, in a Java archive (JAR) file contained in the broker archive (BAR) file that is used to deploy the flow containing the JavaCompute node.
Any Java classes deployed in this way are loaded by an execution group-wide classloader. Whenever a new or changed JAR file is deployed, the execution group-wide classloader is deleted and recreated with all the currently deployed JAR files. At the same time all JavaCompute nodes refresh the Java classes being used within them, as well as recreating all the Java static variables. It is possible to modify this behavior by using the JavaClassLoader configurable service property on the node, which allows alternative classloaders to be used. For more details, see JavaCompute node classloading using a configurable service.
The execution group-wide classloader first searches all the deployed JAR files for a required class. If a required class cannot be found, it defers to the shared classloader. The shared classloader looks in a set of directories on the broker 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 JavaCompute 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 broker 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 WebSphere® Message Broker and can cause conflicts). JavaClassLoader configurable service can also be used to isolate JavaCompute nodes in the same execution group.
- 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 execution group-wide classloader.