In Geronimo each plugin or module has an associated classloader. These classloaders differ from normal URL classloaders in that they have multiple parents and various ways to customize the visibility of classes in the classloader itself and its parents. Classloaders associated with plugins are the only classloaders in Geronimo. Classloaders are uniformly configured in xml through an environment element allowed at the start of all geronimo plans.
The contents of a classloader are specified through dependency elements in the xml environment element. All dependencies refer to artifacts in the geronimo repository, using the same format as dependencies in a maven 2 pom. These dependencies can be plain jars or other plugins. Plugins become parents of the classloader whereas jars become available directly in the classloader.
There are a number of customizations available for classloaders.
Normally when loading a class the parents are searched first. By including <inverse-classloading/> the classloader is configured to search itself first, then the parents. This feature is probably most familiar in web app classloaders but can be configured on any geronimo classloader.
If you have configured inverse-classloading, you can override that for specific classes or packages by including filters for those classes you want to be loaded from parent classloaders even if they are present in the current classloader.
Including a filter in a hidden-classes element prevents matching classes from being loaded from any parent classloader. This is used when the current module depends on a different version or when the class represents a framework that must be initialized independently from the same framework used by the parent.
Including a filter in private-classes prevents and child classloader from loading the class from this classloader. It is similar to hidden-classes but on the parent rather than the child.
A few jars are needed to set up the geronimo kernel and repository and logging and cannot be loaded from the geronimo repository. These jars are configured in a manifest-classpath in the jar manifest of startup plugins such as j2ee-system and client-system. These jars are copied under simpler names in bin and locate the jars in the lib directory. The relationship between the bin and lib directories must not be changed.
Plugins are combinations of both classes and services. Dependencies can be on either classes, services, or both. Normally dependencies are on both. If this is not desired, the import element can be used in a dependency. Lets suppose we have a plugin B with a dependency on plugin A.
Starting plugin B will load plugin A so its classloader is available but will not start plugin A so the services will not necessarily be started. This is used in deployer plugins so that the runtime classes are available but e.g. a web server is not running.
Starting plugin B will load and start plugin A so the services from A are available. However the classes in plugin A will not be available to plugin B. (This is apt to work only if the services in A implement interfaces available to B).
Starting plugin B will load and start plugin A and the both the classes and services from A are available for plugin B.
Some functionality is included in the vm but is intended to be user-replaceable. This includes the xml and xsl libraries. Usually you can't just include the version of xerces or xalan you want to use in your application, instead you need to put it in <geronimo_home>/lib/endorsed. Unfortunately this means all of geronimo will be using the same version of these libraries. A typical symptom of this problem might look like this:
java.lang.ClassCastException: org.apache.xerces.parsers.XIncludeAwareParserConfiguration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration