Table of Contents
All services in Geronimo are defined by GBeans, where a GBean is the
smallest component that can be individually configured in Geronimo. The
smallest unit that can be deployed is a Module, which is a collection of
GBeans. While the deployment tools operate on entire module, it's possible
for individual GBeans to be managed (properties changed, etc.), either
through the admin console or by editing
var/config/config.xml.
This chapter discusses GBeans and Modules, starting with a more detailed overview, and then discussing the code required for a GBean, how to construct Modules of GBeans and configure GBeans for deployment, how to deploy Modules, and how to update the configuration settings of a GBean running in Geronimo after it has been deployed.
A GBean is an atomic service component in Geronimo. A GBean may provide a service (alone or in conjunction with other GBeans), it may be a wrapper around a third-party service component (perhaps acting only as a configuration layer for some other services), or it may represent a deployed component at runtime.
GBeans that are services themselves typically implement at least one service interface and either expose certain service operations or provide start and stop methods to initialize the service for external input (such as binding to a port to receive network requests). These GBeans often have attributes for configuration purposes (such as an int type attribute for the port to bind to). Normally the required attributes are set via constructor arguments, and the GBean has setters for optional or user-configurable attributes.
GBeans that wrap third-party services often emphasize configuration attributes and references to other GBeans, though they may also have operations that they pass through to the underlying service. Note that if the third-party service is essentially a JavaBean, it's possible to store the required metadata in a separate location but use the regular third-party class as the GBean implementation class (though this only works if the GBean class doesn't need lifecycle methods like start and stop). Otherwise, the GBean class normally creates a private instance of the third-party service in its constructor or start method, and its attribute getters and setters either pass the values directly through to the underlying service or save them up and pass them to the underlying service during the start operation.
The third main use of GBeans involves application components that are deployed via the Geronimo deployment system (using the deploy tool, console, Maven plugins, etc.). During a deployment operation, the deployer converts the supplied application classes and XML data into a Geronimo module, which contains one or more GBeans. In other words, anything that is to be loaded or run when the deployed application module is started must be represented as a GBean, and when the module is started, the GBeans will be started. This is not that different in concept from a service module containing only GBeans, but where in a service module the GBeans are defined explicitly, in an application module the deployer derives the GBeans from the application classes and deployment information.
A GBean is a Java component, similar to a JavaBean or JMX MBean. There are few requirements on a GBean class -- the main one being that it must supply a GBeanInfo object (via a static method) containing the metadata describing the GBean. Ultimately, each GBean instance must be configured with a unique name, and GBeans can refer to each other by name, name pattern, or interface.
The GBean's metadata (GBeanInfo) describes the public interface for the GBean, including:
A GBean's constructor is used as part of the configuration process, and may include any number of configuration properties for the GBean.
A GBean attribute is the same as a JavaBean property -- a value where the GBean has a getter and/or setter method of the same type, normally following the JavaBean naming conventions.
A public method other than a getter or setter.
An interface that the GBean implements. Callers can search for GBeans that implement a particular interface, and the most common way to interact with a GBean is to get a proxy that implements an interface and calls the GBean under the covers. GBeans can also be bound into the JNDI space of a J2EE component by interface.
Note that it doesn't matter as much what features the GBean implementation class has, it matters what features the GBeanInfo declares. For example, the GBean implementation class may have three constructors and implement four interfaces, but if the GBeanInfo only lists one constructor and one interface then that one constructor will be the one used and that one interface will be available to search on, create proxies to, and so on.
Other than the GBeanInfo, a GBean implementation class must either have a public constructor that takes no arguments, or implement at least one interface. This constructor and interface need not be used in practice, but the underlying infrastructure requires that each GBean class have one or the other.
There are several optional elements for GBeans. A GBean may
implement the GBeanLifecycle interface, which has
start and stop methods (normally used by GBeans that must take some
action such as binding to a port or starting a service). A GBean may
also take advantage of certain "magic" attributes provided by the
container, including the name of the current GBean instance, the
ClassLoader for the current module, the Kernel that loaded the GBean,
etc. These work like normal GBean attributes, but they are not
configurable by a user, they are provided by Geronimo every time the
GBean is started.