Overview
The Module View contains high level information about how Geronimo is organized into subsystems and packages. It's also intended to give a high level picture of what each module/subsystems purpose is and how it communicates with other modules/subsystems. For the purposes of this document, the focus with be the modules directory in the Geronimo Source. It's likely that this page will change as I gain a better understanding of what the modules/subsystems do and how they communicate with other modules/subsystems.
Subsystems
A subsystem is a logical grouping of modules. Below is a list of subsystems and the modules assigned to those subsystems:
Subsystem |
Module(s) |
---|---|
ActiveMQ |
ge-activemq-rar |
Web Services |
geronimo-axis |
JavaMail |
geronimo-activation |
Clustering |
geronimo-clustering |
JCA |
geronimo-connector |
Deployment |
geronimo-deploy-config |
Java Persistance API |
geronimo-persistence-jpa10 |
J2EE Management Model |
geronimo-management |
Jetty |
geronimo-jetty |
Tomcat |
geronimo-tomcat |
JNDI |
geronimo-naming |
JAAS |
geronimo-security |
Shared/Utility |
geronimo-common |
Unclassified (still todo) |
geronimo-client |
ActiveMQ
ActiveMQ is an Apache implementatino of a Message Bus. It's supports JMS 1.1 and is developed separately from Geronimo. More information can be found here. It's important to note with this subsystem that the code in Geronimo around ActiveMQ are just a wrappers (specifically a GBeans). There are three modules in this subsystem. The ge-activemq-rar modules contains the ActiveMQ RAR (from the ActiveMQ project), the geronimo-activemq-gbean module contains the GBean wrappers around ActiveMQ and geronimo-activemq-gbean-management contains the interfaces for accessing the subsystem externally. An example of how this subsystem is used externally (specifically the externally usable interfaces) is by the console. The console accessed the subsystem through the interfaces in geronimo-activemq-gbean-management, retrieved via GBean.
Web Services
Clustering
J2EE Management Model
This subsystem is Geronimo's implementation of the Sun's J2EE Management Model (or JSR 77). The purpose of this subsystem is to provide generic interfaces for Geronimo's specific implementations. For example, in the geronimo-management modules there is an interface called JMSBroker that is implemented by the ActiveMQBroker. TODO: Does this belong in with the Deployment stuff? The geronimo-j2ee-schema and the geronimo-j2ee-builder modules both look to be deployment related.
Jetty and Tomcat
Jetty and Tomcat are both web containers that are available for use with Geronimo. These web containers are not maintained by the Geronimo developers however there are GBean wrappers to many of the operations for the Jetty and Tomcat servers. The code these subsystems are meant for adapting these projects into the Geronimo application.
JAAS
JAAS is an Authentication and Authorization specification created by Sun. Geronimo has implemented this specification for use by applications deployed in Geronimo. There are two modules in this subsystem. The geronimo-security module contains the code that implementats the JAAS specification. TODO: maybe break this into it's own page?
JavaMail
JavaMail is a specification put out by Sun to abstract away some of the details of creating an Email in Java. Geronimo wraps these standard JavaMail classes so that they can be accessed and managed via GBeans. An example of how these are wrapped is the javax.mail.Session class. The Session class manages configuration and authorization information. In Geronimo, the Session class can be accessed via org.apache.geronimo.mail.MailGBean in the geronimo-mail module. JavaMail also uses the JavaBeans Activation Framework (JAF). The JavaBeans Activation Framework is intended to help identify the contents of the various attributes in JavaBeans. In the case of the JavaMail framework, it's used for MIME types. Geronimo has extended JAF to handle data from the MIME types, these classes are in the geronimo-activation module.
J2EE Connector Architecture (JCA)
The J2EE Connector Architecture is a vendor independenct specification for connecting and communicating with Enterprise Information Systems, such as Enterprise Resource Planning (ERP) systems. The Geronimo implementation of this is available in the geronimo-connector module. The associated gerinomo-connector-builder module is used for converting the XML deployment plans into run-time connectors.
Java Naming and Directory Interface (JNDI)
This subsystem contains an implementation of the Java Naming and Directoring Interface. The geronimo-naming module contains all of the classes to handle JNDI lookups and expose those classes via GBeans to the rest of the Geronimo server. The geronimo-naming-builder reads in deployment plans and creates new entries in the running JNDI contexts.
Java Persistance API (JPA)
The Java Persistance API is a specification added to EJB 3.0 to allow easier persistance of EJBs. Geronimo uses Apache's OpenJPA implementatin of JPA. More information on it can be found here. The purpose of the code in Geronimo around JPA Is wrapping the JPA code in a GBean. In the geronimo-persistance-jpa10 module, the PersistenceUnitGBean class allows access to the OpenJPA routines through the GBean. The geronimo-persistance-jpa10-builder module creates the persistance GBeans at runtime, from the XML config files.
Shared
The shared subsystem contains modules used by many other subsystems and also code that is used by various application server utilities and the demo applications that are shipped with Geronimo.
geronimo-kernel
See Geronimo Kernel
geronimo-derby
Apache Derby is a Java based relational database included with Geronimo. It's small memory footprint allows it to be embedded in applications. Derby is used in Geronimo for several things. First, Geronimo comes with several example applications that use a database, rather than require an external database to be installed, Derby was included. Derby is also used to help make searchable log files. The geronimo-derby module wraps Derby and exposes it as a GBean.
geronimo-timer
This module creates a cron like system for Geronimo. It utilizes the java.util.Timer class to schedule the execution of various tasks. It also allows the tasks to be transactional.
geronimo-converter
This is a small module that contains code to convert datasource configurations from the format used in BEA's Weblogic and JBoss's Application Server. It's only used by the console for creating new datasources.
geronimo-upgrade
The geronimo-upgrade module contains code to aid in the migration from one version of Geronimo to another. Utility code to migrate one version of a deployment plan to another can be found here.
geronimo-directory
geronimo-directory provides access to the LDAP server embedded in Geronimo. The embedded LDAP server is provided by the ApacheDS project and is used for some demo applications that ship with Geronimo.
geronimo-transaction
This module is Geronimo's implementation of the Java Transaction API specification. The specification essentially has 4 required interfaces: UserTransaction, Transaction, TransactionManager, and XAResource. Implementations of these four interfaces are found in the geronimo-transaction module. The implementation of Transaction (TransactionImpl) is used by the application server for transaction aware processing. The UserTransaction implementation (GeronimoUserTransaction) is used by the web containers (Jetty and Tomcat) for usage in deployed web applications. TransactionManager is used when the application server manages the transactions for the application automatically (such as with some EJB operations). Finally the XAResource implementation (used through NamedXAResource in Geronimo) implements X/Open CAE Specification transaction standard.