Geronimo Modules and Assemblies

It should become clear that since Geronimo server components are all modules composed of GBeans, you can readily mix and match the different server components to create different versions of Geronimo. If this is the way you’re thinking, you understand the essence of Geronimo. In fact, an entire chapter (Chapter 18) is devoted to this very important topic.

For now, you should realize that the J2EE server you get when you download Geronimo is only one of the infinite number of personalities that the Geronimo server can take on. Little-G, the minimal server download, is another possible personality. Each of these personalities is called an assembly in Geronimo.

It is this J2EE server assembly (a specific combination of modules) that is J2EE 1.4–certified. In fact, other famous Geronimo assemblies exist. You may have heard of (or worked with) the Gluecode server or the IBM Websphere Application Server Community Edition. These are two famous Geronimo assemblies that are made into actual commercial products.

An assembly, then, is a grouping of a modules (a combination of server components) that provides a Geronimo instance with its feature set - and hence its personality. Assemblies are the different ways you can create a server out of the various server components available to Geronimo.

For example, you may want to put together a Web-tier-only server. For this, you will probably include either Jetty or Tomcat and leave out OpenEJB and ActiveMQ. You can create a custom Geronimo assembly for this. The end result will be a lighter-weight server occupying less disk space and memory. The Geronimo developer has created this very assembly; it can be downloaded as the Little-G minimal server.

Creating new assemblies is an involved task that requires the downloading of the Geronimo source code and a rebuild of the Geronimo server using a Java compiler. Chapter 18 covers this advanced process in more detail.

Both assembly and modules are cornerstone grouping mechanisms within the Geronimo architecture. Table 5-1 summaries the features of these two important concepts.

Table 5-1: Assembly versus Modules
Open table as spreadsheet

Grouping MechanismItems	Being Grouped	Occurs at	Additional Comments
Assembly	Modules	Geronimo Build time	Modules comprising an assembly are specified in system deployment plans.
Module	GBeans	Geronimo server run time	Wiring and GBean attributes parameterization specified in deployment plans.

In Table 5-1, one very important thing to note is that assemblies are bound together at Geronimo build time. This means that the composition of Geronimo assemblies cannot be easily altered without rebuild (from source code) of the Geronimo server.

Since the composition of an assembly is fixed, the code of the server components in an assembly (together with all the APIs libraries that they may be dependent on) can be organized for optimal access during run time. This organization results in the creation of a repository of code and dependent library modules associated with an assembly. You will find the executables of all the familiar server components (such as Tomcat, Jetty, ActiveMQ) all located in the repository. These libraries and code modules in the repository will not change, unless the assembly is rebuilt.

The idea of maintaining modules and dependencies in a repository is not the Geronimo team’s invention. Instead, it is a best practice that originated from the Maven (now Maven 2). Maven 2 is another Apache project (details at http://maven.apache.org). Maven is a project-building and -management framework. Geronimo designers borrow best practices from Maven-including the repository, the module ID concept, plug-ins, and so on.

The remainder of this chapter examines the directory structure used by Geronimo in great detail and will cover the content of the repository along the way.