Overview

This section discusses the Geronimo Kernel. Before getting into the higher level overview of the Geronimo architecture as a whole, it's important to understand the kernel. Through the kernel, GBeans in Geronimo can communicate with the management utilities while being loosely coupled and not tied to JMX. This loose coupling that the kernel provides also makes testing much easier, and allows dependency management and injection. The kernel keeps track of the various GBeans in the system along with the various dependencies, references to other GBeans, attributes and methods. Below is a high level overview of the Geronimo kernel:

The Geronimo Console is a web based way to deploy/start/stop applications, change JMS information etc. In addition to the Geronimo console, this could be some custom written tool, or some other J2EE management software. If a user wanted to stop an application using the Geronimo Console, the user would log into the web console and select the application to stop. When the action to stop the application occurred, the web console wouldn't access Tomcat directly. Instead the web console would query the kernel (through an MBeanServer) for the Tomcat GBean and then the kernel would reflectively execute the appropriate stop function in Tomcat. Note that this allows testing of the web console, the kernel and Tomcat separately from each other. All of the operations on the GBean occur via calls to an implementation of the Kernel interface allowing the implementation details of the kernel to change with minimal impact to the system. Behind the scenes, the BasicKernel class that implements the Kernel interface and employs the assistance of many other classes. These other classes are all hidden behind the Kernel interface.

Kernel

The Kernel interface is where it all starts. Below is a class diagram of Geronimo Kernel. Note that many details have been ommitted, such as each of the methods of the Kernel interface, so as to not cloud the core concepts of the kernel.

The purpose of the kernel is to operate on GBeans that are hooked into Geronimo. In the above diagram, Kernel is an Interface and BasicKernel and KernelGBean are shown to implement that interface. The kernel is wrapped in a GBean just like Tomcat or ActiveMQ are. To achieve this, KernelGBean is a Decorator of Kernel. An instance of Kernel is passed in via the constructor and so all of the methods of Kernel are delegated to that instance. The new functionality that is added to Kernel is the getGBeanInfo() method, needed to make Kernel a GBean. BasicKernel is the concrete implementation of Kernel and has the functionality to manipulate GBeans. Calling getAttribute() for a given GBean will return the results of calling the getter method passed in via the method parameters (those parameters will be discussed in detail below). The invoke() methods, similar to the getAttribute() methods, will execute a particular method on the GBean. Note that other normal operations that you'd want are there as well, like starting or stopping a GBean.

Referencing GBeans

In the above class diagram, the Kernel class has a method named loadGBean(). This method takes an instance of GBeanData (which is essentially just a wrapper around GBean information) and a classloader as input. Recall from GBeans that GBeans aren't required to implement any interface. So the GBeanData object wraps information on how the GBean should be accessed (it's name) and methods/attributes of that GBean. BasicKernel takes the GBeanData and passes it to GBeanInstance to create the object that will be used for all references to that GBean. GBeanInstance has all of the methods that are able to be called, links to the references and dependencies on the other GBeans etc. Dependencies are injected here as well. One of the most important pieces of information that is contained in the GBeanInstance is how it's referenced. Looking through the javadocs for the kernel (link here) will reveal that many of the methods in the interface are overridden four times. Each of the overridden methods have similar method signatures. This is because there are four possible ways to reference a GBean. There is the abstract name, the short name, the object name (looking up GBeans by object name has now been deprecated) and the class type. Below is a table of the four types with definitions of each of the names:

Although there are four ways to access a GBean, essentially there are only two, and then two short-hand ways. If a bean is referenced via a Short Name, or via it's Type, all of the abstract names are queried looking for which abstract name the type or short name belongs to. Then once that is found, it is referenced by Abstract Name. In the BasicRegistry, there are two data structures of GBean references. One for Object Names and one for GBeans. When a GBean is added an entry is made for both to enable fast searching by Abstract Name or by Object Name.