Scenario One: Integration Server Knows Where the Class Lives
In this scenario, a service from PackageA calls a class that Integration Server knows resides in PackageX. PackageA is dependent on PackageX.
The manifest.v3 files for both PackageA and PackageX specify "server" as the class loader, which means that the package class loader is to defer the search to its parent, which in both cases is 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 looking for the class itself, passes the request up to its parent class loader, which is the Integration Server class loader.
3. The Integration Server class loader passes the request up to the OSGi bundle class loader.
4. The OSGi bundle class loader does not find the class.
5. The request comes back to the Integration Server class loader, which searches for the class, first in cache, and then in the Integration Server classpath.
6. The Integration Server class loader does not find the class.
7. The request comes back to PackageA's class loader, which searches for the class, first in cache, and then in the following directories under the server instance’s home package directory (IntegrationServer\instances\instance_name\packages\package_name), in this order:
PackageA\code\jars
PackageA\code\classes
PackageA\lib
PackageA\resource folders
8. PackageA's class loader does not find the class in any of these directories.
9. PackageA's class loader delegates the search to PackageX's class loader.
10. PackageX's class loader searches for the class in cache and then in:
PackageX\code\jars
PackageX\code\classes
PackageX\lib
PackageX\resource folders
11. PackageX's class loader finds the class in PackageX's resource folder.
Contact Support
|
Community
|
Feedback