Hello,

[Reference - 9.7 IS Administrator guide, page no. 43]

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.

Scenario Two: Integration Server Does Not Know Where the Class Lives

In some cases, Integration Server will receive a request to load a class, but is not given
any information about where the class lives.
In this case, steps 1-6 are the same as in Scenario One, but because Integration Server
does not know which package contains the class, it cannot go directly to the class
loader for a particular package. Instead, Integration Server will start looking through all
packages in the Integration Server_directory\instances\instance_name \packages directory.
If you know which packages are most likely to contain the classes being searched for,
you can reduce the number of packages searched by specifying the order in which
Integration Server is to search packages. You control the search order by using the
watt.server.classloader.pkgpriority server configuration parameter. For example, you
could specify the following:
watt.server.classloader.pkgpriority=PackageD,PackageF
With this setting, Integration Server will search PackageD and PackageF for the class
before searching in PackageA, PackageB, and PackageC.

In Scenario 1, how does IS know the class files required for service in PackageA resides in packageX? Is this because we have set packageA depends on package X in manifest file? if yes how it will flow if we don’t set dependency?

In scenario 2, It is mentioned “Integration Server will receive a request to load a class, but is not given
any information about where the class lives” I don’t understand how a client HTTP request specifies the location of class file which is required by a service it calls.

can anyone please help me to understand?