Class Loading System 

Purpose

The class loading system provides options for managing and monitoring of the class loaders. It is represented by the Class Loader Manager and the Java Class Loader Viewer in SAPNetWeaver Administrator.

You can use the Java Class Loader Viewer to monitor the class loaders, their registering and unregistering, parent-child relations, and resources.

You can also use shell administration commands to monitor the class loaders.

More information: Troubleshooting: Finding Missing Parent-Child Relations.

Features

The class loaders may have one or more parents and a set of resources (JAR files and folders). When a new class loader is created by the Class Loader Manager, it is automatically registered with its parents and resources. The resources are set in a specific order.

Once a class loader is created, its parents and resources and their order cannot be changed.

You cannot modify the parent-child relations between class loaders during runtime. We recommend that you do not modify parent-child relations manually as it might lead to problems within the AS Java.

No cyclic dependencies are allowed in the class loading hierarchy.

When a loader searches for a class from its own resources, it follows the specified order until the requested class is found.

We recommend that you do not have one and the same class twice in the loader resources. The loader is able to load only the class that is reached first.

The class loading is performed according to a delegation model, which is determined by the following rules:

●      Transitivity

When a certain loader is requested to load a class, it delegates the request to its parent loaders. The parents then consecutively delegate the request to their parents and so on to the top of the hierarchy.

●      Parent first

When requested to load a class, the loader first delegates the request to its parents. Only if the parents are not able to load the class, the loader tries to load it by itself.

Every time a loader delegates a request, it follows a strict order, which is defined on creation of the loader.

When a loader is not used anymore, the Class Loader Manager unregisters it. Then the loader resources are released and all information about it is removed from the Class Loader Manager.

After a loader is unregistered, no references to that loader (as an object) are allowed. If you try to use the unregistered loader, you get IllegalStateException.

There is an order for unregistering loaders called “children first”. According to this order, a loader can be unregistered only after all its children have been unregistered. If you try to unregister a loader that still has a registered child, you get IllegalStateException.

Example

The delegation model in the class loading hierarchy can be illustrated by a scheme, in which arrows show the child-parent relation. The order of the arrows that come out from a certain loader from left to right, shows the sequence of the loader parents.

If a loader (for example, L10) is requested to load a certain class, the Depth-First Search (DFS) algorithm is used. This means that the loader delegates the request to its parent loaders, which then consecutively delegate the request to their parents and so on to the top of the hierarchy.

 

No cyclic dependencies are allowed in the class loading hierarchy.