Class Loading System 

Purpose

Class loaders are part of the Java Virtual Machine (JVM). When a cluster node needs a new class (at start up, or at runtime,) the JVM invokes the class loader associated with the request to locate and load the class. The class loaders’ main responsibility is to find the class using a parent delegation model and search their own class paths. This powerful dynamic loading mechanism for software components fully complies with the J2EE™ specification.

The SAP J2EE Engine class loading system is centralized in the ClassLoader Manager. It implements functionality used for registering and removing loaders and references between them, as well as for accessing these loaders.

The system comprises several different types of loaders as a result of the SAP J2EE Engine layers division:

·        Core layer – the lowest level. Appears as a group of managers that offer I/O, thread management, clustering, client connections manipulation, and has a similar kind of functionality as the services.

·        Components layer – implements all that is required to comply with the J2EE™ specification (containers, naming, and so on), including helper services for maintaining persistent data, security service, file copying service, and RMI over P4 protocol.

·        Framework layer – the medium between managers and services is called the service framework. It contains interfaces for structured and convenient access to the managers’ functionality.

·        Application layer – deployed applications are the highest and most volatile level of abstraction.

Features

The ClassLoader Manager is the central repository for registering and removing loaders and references between them. This manager provides interfaces for accessing resources and references of specific loaders.

Each loader is distinguished from the others by its name, which obeys the following convention:

·        The loader of each interface is named interface:<interface_name>.

·        The loader of each library is named library:<library_name>.

·        The loader of each service is named service:<service_name>.

·        Loaders that have cyclical references are named common:<loader_name>;<loader_name>;…, where <loader_name> means library, interface, or service loader name.

·        The loader of each application is named by the Deploy Service when the application is deployed.

Registration and unregistration of a loader, as well as registration and unregistration of references is done by name.

Loaders in the cluster node are isolated to offer access to specific and unique bundles of classes only. When loading a class, a class loader first "delegates" the search for the class to its parent class loader before attempting to find the class itself, and finally iterates through its registered references from the ClassLoader Manager.

For more information about class loader references, see Class Loader References.

It is a general rule that multiple copies of the same class lead to a java.lang.ClassCastException or to a java.lang.LinkageError. So, classes that are loaded and resolved in a loader must not be loaded or resolved in any other loader that is linked with this loader (using a parent or reference relationship).