4.5. ClassLoaders in Geronimo

4.5. ClassLoaders in Geronimo
	Chapter 4. Elements of Geronimo [DRAFT (1.1)]

Each module (service module, application module, or resource module) has its own ClassLoader. The hierarchy of ClassLoaders matches the hierarchy of modules. So if a Web Application module has an EJB JAR as its parent, then the ClassLoader for the EJB JAR will be the parent of the ClassLoader for the Web Application. Clearly the ClassLoader arrangement is one of the key reasons to configure the module dependencies in Geronimo.

Within an application EAR, EJBs and RARs are loaded in one ClassLoader, while Web Applications are loaded in a child of that ClassLoader. The ClassLoader hierarchy for an EAR including one module of each type and using a database would look like Figure 4.2, “EAR ClassLoader Hierarchy”.

Figure 4.2. EAR ClassLoader Hierarchy

TODO: THIS DIAGRAM MUST BE UPDATED!!

Notes on Figure 4.2, “EAR ClassLoader Hierarchy”:

The ClassLoaders with a white background are created by Java -- the first two cover the internal JVM classes, and the last includes the command-line argument (which includes a trick to load tools.jar containing the Java compiler).
The ClassLoaders with a grey background are created by Geronimo. The geronimo/j2ee-server/1.1/car configuration loads all of the critical classes and services for J2EE applications, which is why it's automatically added as a dependency for J2EE applications.
Dependency JARs listed in Geronimo deployment plans are loaded in the same ClassLoader as the module that declares them. In the case of the database pool, the JDBC driver is loaded as a dependency. If the resource adapter in the EAR declares dependencies, they'll be loaded with the rest of the EJB and Connector classes in the ClassLoader for the EAR.

The full module hierarchy in a Geronimo server can be quite complex. Here's an example:

Figure 4.3. Geronimo Module Graph


4.4. Introduction to Deployment		Part II. Configuring Geronimo