Class Loading Process
As stated earlier, the class loading process is affected by a number of factors, including the following:
Whether a package uses its own class loader or defers to the
Integration Server class loader.
A package's manifest.v3 file controls a number of characteristics of a package, including whether the package's class loader defers to its parent class loader. The default is to defer to the parent class loader. However, Integration Server will use the package class loader instead, if the following is specified in the manifest.v3 file:
<value name='classloader'>package</value>
If you use the package class loader, the jar files containing the classes you want to make available must be in the
Integration Server_directory \instances\
instance_name\packages\
packageName\code\jars directory. For more information about using a package class loader, refer to
Using a Package Class Loader.
How
Integration Server searches for a class when no package information is available.
When the Integration Server receives a request to load a class for which no package information is available, by default, it will search all packages in the Integration Server_directory \instances\instance_name\packages directory. To potentially save search time, you can control the order in which packages are searched by using the watt.server.classloader.pkgpriority server configuration parameter.
The following sections provide scenarios that describe how the class loading process works, and how the changes to the manifest.v3 file and watt.server.classloader.pkgpriority server configuration parameter affect that process.
