4.2. The Kernel and GBeans

4.2. The Kernel and GBeans
	Chapter 4. Elements of Geronimo [DRAFT (1.1)]

The Geronimo core, or kernel, is small and basically responsible for managing the lifecycle and dependencies of all the individual components that run within Geronimo. Those components may be services (such as a transaction manager), resources (such as a database pool), or applications (such as a web application). The kernel also manages the process of hooking individual components up to each other, so separate components can work together at runtime. For example, the web application service (usually Jetty or Tomcat) needs a reference to every web application that starts, so when it gets an incoming HTTP request, it can dispatch it to the appropriate web application.

A diagram of a simplified Geronimo runtime might look like this (don't worry about the specific services yet, but look at the relationship between the kernel and the components):

Figure 4.1. Components in a Geronimo Runtime

TODO: Replace this with a better-looking diagram

In Figure 4.1, “Components in a Geronimo Runtime”, the solid bars indicate that the kernel starts and manages all of the other components. The dashed lines indicate that the individual components communicate with each other once they're up and running. The diagram is a little busy, but note that the kernel is ultimately responsible for the lifecycle of all of these components. Components don't load or manipulate each other directly; instead the kernel sets up the components and provides the communication pathways between them.

4.2.1. Geronimo Managed Components: GBeans

Every component managed by the kernel is a Geronimo bean, or GBean. Further, some components are broken down and deployed as multiple GBeans, for more fine-grained monitoring and management. For example, when a J2EE application is deployed, a number of GBeans are deployed representing (among other things):

The application
Each J2EE module within the application (EJB JAR, web application WAR, etc.)
Each servlet in a web application
Each EJB in an EJB JAR
Each connection factory or admin object configured for a J2EE connector

While GBeans representing application components are automatically created and deployed by the server, most GBeans can be configured and deployed manually. GBeans can declare read/write attributes, allowing the administrator to configure the GBean (for example, setting a port for the web application service to listen on). In addition, all GBeans can handle lifecycle events, implementing certain logic that should be run during startup or shutdown (for example, each web listener service starts an HTTP listener during startup, and stops it during shutdown). With these configuration and runtime features defined, GBeans can be monitored, configured, started, and stopped through the standard Geronimo management interface.

If you want to write additional components that should run in Geronimo, you can deploy new GBeans. You may encounter this, for example, if you want to deploy a custom JMS server configuration (see Section 7.5.2, “Message Broker GBean Configuration”), or if you want to add a brand new service. GBeans can be deployed as part of an application configuration, or as top-level standalone components in the Geronimo server. The same tools are used to deploy and manage GBeans as to deploy and manage J2EE applications -- there is not much of a distinction between application module and service modules.

	Tip
	For a more detailed discussion of GBeans, including information on developing GBeans, see Chapter 18, GBeans: Adding New Services to Geronimo [DRAFT (1.1)].


Chapter 4. Elements of Geronimo [DRAFT (1.1)]		4.3. Server Startup and Modules