Class Loader Structure
(Server DAG) Shared
App1 App2 ...
Contains the standard java class library (e.g. java.lang.*) and any classes contained in jars from the System Extensions directory ($JAVA_HOME/jre/lib/ext). This class loader is automatically created by the Java Virtual Machine and is normally not even accessible to applications.
Contains the Jar files and directories specified on the command line when invoking the Java executable. In XBean, this will only contain the bootstrap.jar.
Contains the jars in the bin/lib directory. Normally this will only be the jars necessary to load and run the bootstrap.xml file, and this class loader should be garbage collected after the main system is started.
Contains the jars and classes in the common/lib and common/classes directories respectively (see Tomcat Style Layout). Normally, this class loader is empty, but it is sometimes useful for the distribution of patches.
The class loader directed acyclic graph (DAG) is a child of the common class loader. Each artifact from the repository will be contained in a separate class loader and will be child of each artifact it has a runtime dependency on as defined by the maven pom.
Contains the jars and classes in the shared/lib and shared/classes directories respectively (see Tomcat Style Layout). Normally, this class loader is empty, but it is sometimes useful for quick class path extension. It is recommended that the repository be used instead of a shared class loader as it is much easier to control and manage the visible classes.
Each class loader has the classes contained within the application. The picture above is not accurate in terms of apps, since they will tend to have additional parents on class loaders in the server DAG. For example, the a web application will see the classes from it's webapp server and the javax.servlet classes.