4.4. ClassLoaders in Geronimo

4.4. ClassLoaders in Geronimo
	Chapter 4. Elements of Geronimo [DRAFT (1.0-pre)]

Each configuration (server, application module, or resource) has its own ClassLoader. The hierarchy of ClassLoaders matches the hierarchy of configurations. 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.3, “EAR ClassLoader Hierarchy”.

Figure 4.3. EAR ClassLoader Hierarchy

Notes on Figure 4.3, “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.0/car configuration loads all of the critical classes and services for J2EE applications, which is why it's almost always used as the parent configuration for J2EE applications.
The application does not need to directly depend on the database configuration, because the two only interact through the java.sql and javax.sql classes, which are defined at a higher level.
Dependencies 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.


4.3. Introduction to Deployment		Part II. Configuring Geronimo