Add a couple clarifications suggested by Jack Cai, thanks!
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 feature is a bit odd. In addition, all child classloaders will not be able to load the class from any 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.