JavaCompute node class loading
The JavaCompute node loads and runs a Java™ class that is defined as the Java class property on the node. This class is deployed, with any other required classes, in a Java archive (JAR) file.
- You can deploy the JAR file in a BAR file with the container of the message flow that contains the JavaCompute node.
- You can deploy the JAR file directly to an integration server in a shared library that is referenced by one or more applications or shared libraries.
- You can deploy the JAR file in a BAR file in a shared library that is referenced by one or more applications or shared libraries.
Java classes in shared libraries
You can use a shared library to share the Java classes between multiple solutions, or to provide isolation.
Java classes that are deployed in a shared library are not available to the integration server-wide class loader. When you deploy a shared library that contains Java files, a new class loader is created for that shared library. This class loader contains all Java classes in the shared library, as well as the Java classes from all referenced shared libraries. Delegation does not exist from one shared library class loader to another shared library class loader. Java classes in shared library class loaders are isolated from Java classes in the integration server-wide class loader. Similarly, Java classes in the integration server-wide class loader are isolated from the Java classes in any shared library class loaders.
A Java class can exist in multiple class loaders if that Java class is contained in a shared library that is referenced by other shared libraries. When you update that Java class by redeploying the shared library that contains it, all class loaders for all shared libraries that contain that Java class are deleted and re-created.
Integration server-wide class loader
Java classes that are deployed in a BAR file in the container of the flow that includes the JavaCompute node are loaded by an integration server-wide class loader. Whenever a new or changed JAR file is deployed, the integration server-wide class loader is deleted and re-created with all the currently deployed JAR files. At the same time, all JavaCompute nodes refresh the Java classes that are being used within them, as well as re-creating all the Java static variables. You can modify this behavior by using the JavaClassLoader configurable service property on the node, which allows alternative class loaders to be used. For more information, see JavaCompute node class loading by using a configurable service.
The integration server-wide class loader first searches all the deployed JAR files for a required class. If a required class cannot be found, it defers to the shared class loader. The shared class loader 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 JavaCompute nodes need to use. For more information, see Java shared classloader.
If the required class cannot be found in any of the deployed JAR files, or in the JAR files that are installed in the shared classes directories, a class loader that contains all the integration node supplied classes is checked (for example: this class loader contains the jplugin2.jar), followed by the class path, and then finally the Java virtual machine (JVM) system class loader.
Delegation from one class loader to another can occur in one direction only. If a class is resolved in the shared class loader, it cannot create classes directly in the integration server-wide class loader.