ClassLoader Manager 
Purpose
The ClassLoader Manager locates classloaders necessary for the proper functioning of the SAP J2EE Engine. It runs on both dispatchers and servers of the cluster.
Features
The ClassLoader Manager is used as a registry for class loaders running on the SAP J2EE Engine. This manager registers the loaders of all components and applications in the SAP J2EE Engine. The process of registration and unregistration is accomplished mainly by the Service Manager (for components) and the Deploy Service (for applications).
For more information about how the Deploy Service registers and removes loaders, see Application Class Loading.
Class Loader Names
The ClassLoader Manager keeps a hash table of all referenced loaders. The loader name is used in this table as a key, which is unique.
· Component names
¡ Components without cycles
service: <provider-name>/<component name>
library: <provider-name>/<component name>
interface: <provider-name>/<component name>
¡ Components with cycles
common: <provider-name>/<component name>; <provider-name>/<component name>; <provider-name>/<component name>...
· Application names – the name of the application loader depends on the Deploy service and on how the application is deployed.
<application name>
Hierarchy
SystemClassLoader <- FrameClassLoader <- CoreClassLoader
SystemClassLoader <- FrameClassLoader <- ComponentLoader
SystemClassLoader <- FrameClassLoader <- ApplicationLoader
The class loading is accomplished only towards the SystemClassLoader. No opposite direction of loading is available.
Class Loading Sequence
The components in the SAP J2EE Engine class loading system have the following sequence of loading classes:
1. Checks that the class is not loaded by other concurrent thread.
2. Checks its own negative cache – monitors whether any previous attempts to load this class have failed.
3. Tries to load the class through its parent class loader.
If no parent class loader is set, the default parent class loader is the SystemClassLoader.
4. Tries to load the class through referenced class loaders – makes a call to the ClassLoader Manager for its references and tries to load the class through any of them. When a referenced class loader is called, it does not try to load the class through its references – only local class loading attempt is made. This is done to prevent cycles. The level of reference traversing is 1.
5. Tries to load the class locally – searches for the class in the resources, which directly belong to this class loader.
6. If the class is still not loaded, it is added to the negative cache, which is a synchronized structure without size limitation. It is cleared when new resources are added to the class loader. In this case, a ClassNotFoundException is thrown.
In case of application, frame, and core loaders, step 3 follows step 5.
Resources
The main resources available are:
· Simple:
¡ JarResource – one JAR file
¡ DirResource – one directory
· Multiple:
¡ JarsResource – several JarResources
¡ DirsResource – several DirResources
¡ MultipleResource – many resources
Filters
· JarResource – each JAR file has a filter that provides the following functions:
...
¡ Saves expensive operations for reading from the hard drive.
¡ Has a filter representing the JAR package structure. By default, it has 5 names and is filled the first time the JAR file is opened.
¡ On attempt to load a class whose package does not start with any of the stored filters, no disk access is performed. An exception is returned that there is no such class in the JAR file.
· DirResource – has no filters.
See also: