Each class loader is a child of the previous class loader. That is, the application module class loaders are children of the WebSphere extensions class loader, which is a child of the CLASSPATH Java class loader. Whenever a class needs to be loaded, the class loader usually delegates the request to its parent class loader. If none of the parent class loaders can find the class, the original class loader attempts to load the class. Requests can only go to a parent class loader; they cannot go to a child class loader. If the WebSphere extensions class loader is requested to find a class in a J2EE module, it cannot go to the application module class loader to find that class and a ClassNotFoundException error occurs. After a class is loaded by a class loader, any new classes that it tries to load reuse the same class loader or go up the precedence list until the class is found.
The order can also be reversed. Application class loaders load EJB modules, dependency JAR files, embedded resource adapters, and application-scoped shared libraries. Depending on the application class-loader policy, an application class loader can be shared by multiple applications (Single) or unique for each application (Multiple). The application class-loader policy controls the isolation of applications that are running in the system. When set to Single, applications are not isolated. When set to Multiple, applications are isolated from each other.
By default, Web module class loaders load the contents of the WEB-INF/classes and WEB-INF/lib directories. The application class loader is the parent of the Web module class loader. You can change the default behavior by changing the Web application archive (WAR) class-loader policy of the application.
The WAR class-loader policy controls the isolation of Web modules. If this policy is set to Application, then the Web module contents also are loaded by the application class loader (in addition to the EJB files, RAR files, dependency JAR files, and shared libraries). If the policy is set to Module, then each Web module receives its own class loader whose parent is the application class loader.
Tip: The console and the underlying deployment.xml file use different names for WAR class-loader policy values. In the console, the WAR class-loader policy values are Application or Module. However, in the underlying deployment.xml file where the policy is set, the WAR class-loader policy values are Single instead of Application, or Multiple instead of Module. Application is the same as Single, and Module is the same as Multiple.
Liang, S., and Barcha, G. "Dynamic Class Loading in the Java Virtual Machine"
Venners, B. (2000). Inside the Java Virtual Machine. McGraw-Hill Osborne Media.
Neward, T. (2000). Server-Based Java Programming. Manning Publications Company.
Gong, Li. "Secure Java Class Loading"
The Java Servlet Specification
I'm gonna teach you a lesson! Start by looking at this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop