Cloud Application Integration (On-Premises) : Administering Integration Server : An Overview of the Server : How the Server Loads Java Classes : How Class Loading Works : Class Loading Process : Scenario Three: Package Class Loader Does Not Defer to the Integration Server Class Loader
Scenario Three: Package Class Loader Does Not Defer to the Integration Server Class Loader
By default, a package class loader defers the search for a class to its parent, which is always the Integration Server class loader. There may be times, however, when you want the package class loader to perform the search instead of deferring to the Integration Server class loader. For example, you might have a package that contains a newer version of a class than the one Integration Server is using.
To use the package class loader, specify the following in the manifest.v3 file for the package:
<value name='classloader'>package</value>
The following shows how class loading works when the package class loader does not defer to the Integration Server class loader.
1. A service in PackageA calls a class that has not yet been loaded into memory.
2. PackageA's class loader, rather than deferring the search to the parent class loader, performs the search itself, looking first in cache, and then in the PackageA directories, in this order:
PackageA\code\jars
PackageA\code\classes
PackageA\lib
PackageA\resource folders
If the package class loader does not find the class after searching the directories shown above, the class loader moves up the dependency chain, searching packages on which PackageA depends.
Copyright © 2015- 2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback