Class Loading Process
The class loading process is affected by the following factors:
Whether or not
Integration Server knows which package contains the class.
Integration Server knows which package contains the class when a service is being invoked. Integration Server can use the name of the service, which must be unique across the Integration Server namespace, to determine the package in which the service resides. In each of the following situations, Integration Server uses the name of the invoked service to determine which package contains the service and therefore the class.
Integration Server uses the URL or SOAP envelope from a client request to determine which service to invoke.
A flow service uses an INVOKE step to execute a service.
Java code invokes a service by calling the Service.doInvoke() or Service.doThreadInvoke().
Integration Server does not know which package contains the class when a Java service uses Java code to refer to the class. For example, aJava service could call methods in core Java class or in a library that Integration Server or a layered product loads. Because a service is not being invoked, Integration Server does not have a reference to the package that contains the class.
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 a package uses its own 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, Integration Server will search all packages in the Integration Server_directory \instances\instance_name\packages directory. Because the Integration Server class loader maintains the names of package class loaders in a HashMap, which is an unordered collection, the order in which Integration Server searches the packages is undefined. 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.
