Extended Java Class Loading of SAP NetWeaver
SAP Platform Ecosystem
Extended Java Class Loading of NetWeaver
Copyright
© Copyright 2005 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
SAP AG 2005 2 Extended Java Class Loading of NetWeaver
Icons in Body Text
Icon Meaning Caution
Example
Note
Recommendation
Syntax
Additional icons are used in SAP Library documentation to help you identify different types of information at a glance. For more information, see Help on Help → General Information Classes and Information Classes for Business Information Warehouse on the first page of any version of SAP Library.
Typographic Conventions
Type Style Description Example text Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options. Cross-references to other documentation. Example text Emphasized words or phrases in body text, graphic titles, and table titles. EXAMPLE TEXT Technical names of system objects. These include report names, program names, transaction codes, table names, and key concepts of a programming language when they are surrounded by body text, for example, SELECT and INCLUDE. Example text Output on the screen. This includes file and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools. Example text Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation.
SAP AG 2005 3 Extended Java Class Loading of NetWeaver
Table of Contents Extended Java Class Loading of SAP NetWeaver ...... 5 Introduction...... 5 Standard Java Classloading ...... 5 Classloaders and their hierarchy...... 5 How classloaders work together ...... 6 Endorsed Directory...... 7 Extended SAP Classloading ...... 7 Resource Adapters...... 8 Extended SAP classloading in J2EE applications ...... 8 Classloader Manager ...... 9 References in Detail...... 10 Classloader viewer...... 11 Sequence of loading classes...... 11 Sequence of application deployment on the J2EE engine ...... 12 Sequence of Starting a deployed application ...... 12 About the author ...... 12
SAP AG 2005 4 Extended Java Class Loading of NetWeaver
Extended Java Class Loading of SAP NetWeaver
Introduction
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.
Standard Java Classloading
A classloader loads classes into the memory. Every object can be identified explicitly by its class and its classloader.
Classloaders and their hierarchy Classloaders are organized in a hierarchy with a parent classloader and child classloaders. The relationship between parent and child classloaders is like the relationship of super classes and subclasses. But every classloader may have only one parent classloader. This principle is shown in the following illustration.
When a classloader is asked to load a class, it first asks its parent class loader to try to load the class. Only if the parent cannot load the class or if the parent’s ancestors in the classloader hierarchy above cannot load the class, the original classloader will attempt to load the class. Although a classloader can see classes loaded by its parents, it cannot see classes loaded by its children. Based on the same principle the standard Java classloaders are organized in the following hierarchy:
SAP AG 2005 5 Extended Java Class Loading of NetWeaver
Bootstrap classloader
The bootstrap classloader is the parent of the Java classloader hierarchy. The JVM creates the bootstrap classloader, which loads the internal classes of the JDK and the Java packages included in the JVM. For example, the bootstrap classloader loads Java.lang.Object and loads Java.lang.String. Besides this, there are other archives belonging to the bootstrap archives like i18n.jar.
Extension classloader
The extensions classloader is a child of the bootstrap classloader. The extension classloader loads any JAR file placed in the extensions directory of the JDK which is /lib/ext. This works without adding entries to the classpath.
System classpath classloader
The system classpath classloader extends the JDK extensions classloader. The system classpath classloader loads the classes from the classpath of the JVM. Application classloader
Application-specific classloaders (including own implemented classloaders) are children of the system classpath classloader.
How classloaders work together
When a classloader is asked to load a class, it delegates the request to its parent classloader first, which sends it to its own parent classloader and so on up the hierarchy until the class is found. Every classloader first delegates a request for loading a class to its parent classloader.
A class load request is always delegated to the bootstrap classloader first. After this the request is delegated to the Extension classloader and after this the request is delegated to the System classpath classloader. At last, the request is delegated to the Application classloader.
Doing this, classloaders use a delegation model to load a specific class. The classloader first checks whether the requested class has already been loaded. This class verification improves performance in that the cached memory copy is used instead of repeated loading classes from disk. If the class is not found in the memory, the parent classloader loads the class. Only if the parent classloader cannot load the class the classloader itself attempts to load the class. If a class exists in the parent and in the child classloader, the parent version will be loaded.
The sequence of looking for the location of a requested class is organized in the following steps.
1. If a Java program starts the VM looks for the bootstrap classes first. Bootstrap classes are located in the archive rt.jar. Besides this, there are other bootstrap archives like i18n.jar.
2. If the VM does not find the requested classes in the bootstrap archives the VM starts looking for the requested classes in the extension directory next. The extension directory is always located at /lib/ext. If there are any classes located in the extension directory it is not necessary to add entries to the classpath to find them.
3. If a requested class can not be found in the extension directory either, the VM starts looking for this class in all archives declared in the classpath.
In versions of the JDK earlier than version 1.2 the bootstrap classes have to be declared in the classpath, too.
SAP AG 2005 6 Extended Java Class Loading of NetWeaver
Endorsed Directory
It happens once in a while that new versions of standard libraries occur. So that the new versions of these libraries do not have to be taken always in the bootstrap classpath, there is a special directory to deposit updates of these libraries. This directory is called the endorsed directory and it is located at /jre/lib/endorsed.
Alternatively these update classes or archives can be specified by the commandline option Java.endorsed.dirs
If a new version of a class is found in the endorsed directory, the classloader takes this class from the endorsed directory and not from the archive the classes would be loaded otherwise. All classes found in the endorsed directory cover and extend the standard classes.
Not all classes can be overwritten that way. For example there is no way to overwrite the class Java.lang.String with a newer version. [Reason: Only classes for so called endorsed standards can be overwritten. An endorsed standard is a JavaTM API defined through a standards process other than the Java Community ProcessSM (JCPSM)].
There is a documentation which points out which classes can be overwritten and which not. One example of this documentation can be found under: http://Java.sun.com/j2se/1.4.2/docs/guide/standards/
Extended SAP Classloading
You can define and implement expansions of the default classloaders in Java. Based on this possibility, the SAP Web AS offers an extended Java classloading model.
This extended Java classloading model allows the usage of classloader references from and to a classloader. The relationship between referenced classloaders is like associations between classes with the cardinalities 1:1.
This extension of the Java classloading model enables the loading of a class by a referenced classloader like shown in the following illustration.
Assumed, a class shall be loaded via classloader B. Now not only the steps of the standard Java classloading will be executed. In this case, the class is first attempted to be loaded with the help of classloader A which is the parent classloader of classloader B. If loading the class in the parent classloader hierarchy is not successful, the extended Java classloading model of SAP comes into action. It will try to load the class from the directly referenced classloader D. It will, though, not try to load the class from the parent classloader of the
SAP AG 2005 7 Extended Java Class Loading of NetWeaver referenced classloader D and also not from classloader F, which is referenced by classloader D [One could say that there are no indirectly referenced classloaders].
Only if neither the parent hierarchy nor the referenced classloaders could deliver the class, the original classloader B will try to load the class from its class resource locations.
The classloading references have no transitiv behaviour. Even if you have A→B and B→C references, A cannot directly load classes from C. If A depends on C, it will have to explicitly state the reference A→C.
The classes of every server component (services, applications) become instantiated in a separate classloader. The Java kernel and the API's framework have also separate classloaders.
Resource Adapters When a resource adapter is deployed, the system associates it with a classloader. It is used to initialize the adapter’s classes. Resource adapter classloading also defines the access of other components to a resource adapter.
Resource adapter classloading depends on whether you deploy the resource adapter as a standalone module, or as a part of an application. If standalone resource adapters (RAR) are deployed, all of them will be deployed in an own classloader and all J2EE applications are able to access them. If a resource adapter which is bundled in a J2EE EAR is deployed, the resource adapter is only accessible for the J2EE application which belongs to the bundle.
Extended SAP classloading in J2EE applications
Every J2EE application in an EAR or in a standalone J2EE module is loaded in an own classloader. Such a J2EE application can contain web modules, EJB modules, resource adapters etc. Because of this, every component or class is visible in the archives for every other component and can be instantiated or can be used by every other component.
The hierarchy of the extended SAP classloading is shown in the following illustration.
The parent classloader of a J2EE application is the server’s Frame Classloader and above this resides the System Classloader which grants access to all J2SE classes and all classes in the server classpath.
SAP AG 2005 8 Extended Java Class Loading of NetWeaver
The classloader of the J2EE application called the Application Classloader has a reference to all APIs like the Servlet API, EJB API or WebDynpro API. These references do not have to be set by the application developer because they are set by the system automatically.
It can be that a big J2EE application must be structured into more than one EAR or that a part of the application is evacuated into a separated server library to make the library accessible to other J2EE applications. In such cases an application must set a reference to the application or to the library which results in corresponding classloader references.
The class loading is accomplished only up towards the System classLoader. No opposite direction of loading is available.
Classloader Manager The 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 ClassLoader Manager keeps a hash table of all referenced loaders. The loader name is used in this table as a key, which is unique. The system comprises several different types of loaders as a result of the J2EE Engine layer division: Core layer – the lowest level. The Core Layer appears as a group of managers that offer I/O, thread management, clustering, client connections manipulation, configuration management. 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 (excerpt). 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. Classloaders in a 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 iterating through its registered references from the ClassLoader Manager, and finally attempts to find the class itself.
SAP AG 2005 9 Extended Java Class Loading of NetWeaver
References in Detail Classloader references are described in the SAP specific J2EE application descriptor application j2ee- engine.xml. However, usually there are no reasons to write down the references in the descriptors by hand since these are generated by the SAP Netweaver Developer studio automatically. Only if you try to deploy standalone J2EE modules – for example a resource connector which is not bundled in an EAR – you have to describe the references to other components in a different way as explained before. In this case there is no SAP specific J2EE application descriptor. Therefore you have to describe the references in a similar way in the components descriptor. The next illustration shows the classloading structure for a typical J2EE application using classloader references.
The purpose of this mechanism is to hide the complexity from application developers having to explicitly define references between the application class loader and other system class loaders, and register them in the J2EE Engine’s Class Loading System. The Deploy Service has a built-in mechanism that performs all these tasks using the references that the application developer has defined. The mechanism is based on defining references from an application to another component. An application can set references to: • Other applications that are deployed on the J2EE Engine • J2EE Engine components (services, libraries, and interfaces) • A standalone web module (a WAR file) • A standalone EJB module (a JAR file) • A standalone resource adapter module (an RAR file) There is no limit for the number of references each loader can register. From a class loading point of view, each reference has equal weight.
SAP AG 2005 10 Extended Java Class Loading of NetWeaver
There are the following two target types for a reference:
• target application
• target library (component)
Two types of references can be set by a component to another component. Both types can be set only in one direction.
• Weak references will be used if classes are used between two components. If a second component exists a classloading reference will be set from the first component to the second component. For the dissolving of the first component it is necessary that the second component can be dissolved successfully. This means that the second component must have created its classloaders successfully. If the second component shall be unloaded, the system triggers unloading the first component before. Cycles of weak references between components are permitted to infrastructure components only. Cycles of weak references for J2EE applications are not permitted.
• Strong references will be used if the object dependency between two components is functional rather than just of a class-sharing type. If a second component exists, a classloading reference will be set from the first component to the second component. For the dissolving of the first component it is necessary that the second component can be dissolved successfully. All events which are involved in the state change of the second component are sent to the first component. The second component can be started only if the first component is already started. If the second component shall be stopped, the system stops the first component before. If the second component shall be unloaded, the system triggers unloading the first component before. Cycles of strong references between components are not permitted.
• Hard references are deprecated and are equal to the strong references.
Classloader viewer
A view of all all registered class loaders, the full path to their resources, and its classloading references can be shown at runtime with the classloader viewer which is part of the visual admin tool. This service graphically displays the relations between different loaders on a selected cluster element and shows all references for an application or library including the references which are set by default from the server.
This can be useful, for example, if you are tracing an application and if there are similar classes in two different JAR files, you can see which one it is loaded from.
Sequence of loading classes The components in the 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 system classLoader. 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. 5. Tries to load the class locally – searches for the class in the resources, which directly belong to this class loader.
SAP AG 2005 11 Extended Java Class Loading of NetWeaver
6. If the class is still not loaded, it is added to the negative cache, which is a synchronized structure. It is cleared when new resources are added to the class loader. In this case, a ClassNotFoundException is thrown.
Sequence of application deployment on the J2EE engine
1. A temporary EARClassLoader extracts the application EAR file, or application archive components you want to deploy, to a temporary directory. The temporary EARClassLoader registers references to all the components necessary for deployment. EARClassLoader is a standard resource class loader, which is registered in the J2EE Engine class loading system at deployment. It provides containers with the same functions that the real class loader of the application has when the application is started.
2. Each container obtains and uses this class loader to load application classes.
3. The system allocates different application components to the appropriate containers based on the information provided by the application deployment descriptors (application.xml, application-j2ee-engine.xml), and the file name and file extension of the components archive files.
4. The application is locked in the cluster when it performs any of the actions – deploy, update, remove, start and stop.
5. The system creates a database configuration for storing container-specific persistent information about the application.
6. At this step, the system performs the actual application deployment. It is a transactional process and can be committed or rolled back.
7. If the application is deployed successfully on the containers (the transaction is committed), the database configuration is stored to the database. If the transaction is rolled back, temporary information about the application is discarded and the application deployment fails.
8. A notification message that the application is deployed is sent to all other server components in the cluster to notify local containers of the availability of this application.
Sequence of Starting a deployed application
1. Each container downloads its application files from the database to the local file system.
2. An application classLoader is created to load the application classes. This is a standard resource class loader, which is registered in the J2EE Engine’s class loading system at the application start, and it remains there until the application is stopped. It registers references to all the components that the application needs by providing references to their class loaders.
3. The application is actually started. This is a transactional process too.
4. The application is successfully started only if the transaction has been committed. If the transaction is rolled back, the application is returned to the stopped state.
About the author Carsten Lange is a solution architect with focus on Java/JEE technology. He is also an experienced project manager in software development and has been leading development teams for several consulting organizations in Germany and USA.
SAP AG 2005 12