The Apache Software Foundation released version 1.1 of Apache Geronimo in July 2006. This version has not only improved Geronimo's scalability, portability, and overall organization, it has also incorporated several new features and configurations and has changed the way day-to-day operational management tasks are executed.
Apache Geronimo 1.1 is an open source Java 2 Platform, Enterprise Edition (J2EE) 1.4-certified open source application server. Unlike other J2EE application servers, Geronimo comes preintegrated with external resource components like a database, a messaging server, and a directory server. Geronimo is built on a highly customizable and modular architecture. It functions as a framework supporting existing open source components to form a complete J2EE application server package composed of over 30 best-of-breed open source projects. Geronimo is built on the GBeans architecture in which the Geronimo kernel acts as the central core, providing common security, deployment, administration, management, and life cycle services for these components. All the other services built into the server are provided by external components. Developers can custom-build these components for Geronimo or pull them in from other existing open source projects. Geronimo has gained popularity among the open source development community, and the highly anticipated release of its newest version, 1.1, provides several major enhancements to this powerful application server.
The newest version of Apache Geronimo was made available for download as both binary and source-code files for usage with the Linux®, Mac OS X, and Microsoft® Windows® operating systems. Along with its J2EE 1.4 certification, the newest version also includes numerous bug fixes, performance improvements, new support options, and features, including the following:
- An updated deployment plan
- Plug-in architecture
- New repository and modules
- Improved deployment plans
- Enhanced Web Console
- Improved hot deployment
- Shared library
- In-place deployment
The following key technical advantages of Geronimo 1.1 distinguish it from other application servers available today:
- A pluggable framework and a modular architecture, provided by the versatile GBean architecture
- Advantages of falling under the liberal Apache License
- Prepackaged and preintegrated database, messaging, and directory servers
- Low memory and resource requirement
- Driven by an active open source community
- Strategic commitment and optional support from IBM®
The organizational structure of the server has changed from the previous version. All modules and applications are now being stored in a repository, resulting in the repository structure being closely linked with the moduleID provided in the plan file.
Another noteworthy enhancement is the introduction of plug-in architecture. This architecture will change the way Geronimo applications are shipped or distributed, giving developers an extra level of flexibility and simplicity with Geronimo configuration.
The Web Console in Apache Geronimo has undergone several improvements, which are discussed later in the Web Console section.
The previous version of Geronimo, 1.0, was available for download as two different J2EE assemblies -- one based on the Jetty Web Container and the other based on Apache Tomcat. Developers were forced to download all the services mandated by the J2EE specification. Now, with Geronimo 1.1, you can download a shredded version of Geronimo, which can be a huge time saver.
If you're a developer interested in using a lightweight version of Geronimo that's not based on Enterprise JavaBeans (EJB) and that requires very little resource and memory usage, Little-G might be the perfect solution. Little-G allows you to add features and services as required. As the name suggests, Little-G has very low space requirements -- typically around 20MB. Little-G doesn't come with all the components necessary for a full J2EE stack and has minimal Tomcat support. The Geronimo kernel is the basis for both Little-G and the full J2EE version of Geronimo, so applications built for either version are compatible, provided all the dependencies are satisfied. Little-G includes the following essential components and services. (Note that it doesn't contain the Web Console or the EJB, messaging server, or Web services containers.)
- A Web container, with your choice of either the Jetty or Tomcat framework
- A transaction manager provided via Java Open Transaction Manager (JOTM) and custom Geronimo code
- Logging capability via Log4j
- The Geronimo plug-in system
- Java Database Connectivity (JDBC) support via code from TransQL
With Little-G's inclusion of plug-in architecture, you have the option of adding components and services from any local or remote repository with minimal disruption to core services. You can easily upgrade Little-G to meet any of your specific requirements, such as support for JMS or J2EE applications, using plug-ins. (Note that because the deployment tool is included in Little-G but not the Web Console, you're limited to a non-GUI-based deployment.)
When you're ready to download Geronimo 1.1, you'll have a choice of the following following formats:
- J2EE 1.4-certified releases
- Linux, Mac OS X, and UNIX® versions:
- Geronimo 1.1 with Jetty
- Geronimo 1.1 with Tomcat
- Windows releases:
- Geronimo 1.1 with Jetty
- Geronimo 1.1 with Tomcat
- Linux, Mac OS X, and UNIX® versions:
- Linux, Mac OS X, and UNIX versions:
- Little-G 1.1 with Jetty
- Little-G 1.1 with Tomcat
- Windows versions:
- Little-G 1.1 with Jetty
- Little-G 1.1 with Tomcat
- Linux, Mac OS X, and UNIX versions:
- Source code
Geronimo plug-ins are a new packaging mechanism for Geronimo modules. They can be used as a mechanism for distributing Geronimo applications, server features, or integrated products. The new plug-in architecture available with version 1.1 provides an infrastructure to package the existing setup in a format that can be transferred to other machines. Simply put, a plug-in is nothing more than an existing application or service that is exported as an install setup, which can then be installed on your machine from a remote repository.
A Geronimo plug-in repository is a standard central location that provides Maven-type storage space for common and freely downloadable plug-ins. One such common repository is available on the Geronimo Plugins site (see Resources at the end of this article for the link). Many of these repositories allow you to select any location as a repository destination provided the location has a geronimo-plugins.xml file in the root directory that lists the available plug-ins in the repository.
The new Geronimo plug-in architecture, which makes plug-ins a useful mechanism for distributing modules and applications from one development or deployment environment to another, has the following characteristics:
- Any type of Geronimo module, application, or service can be distributed as a Geronimo plug-in.
- Installing a plug-in automatically downloads any dependencies (JARs or other plug-ins) that are not necessarily available with the Geronimo distribution.
- All the resource prerequisites must be satisfied before installing a plug-in or it will fail.
- Because creation of a plug-in requires a complete setup package to be in place, all plug-ins are assured to be complete.
- Dependencies required by plug-ins can be provided within the plug-in repository or any other Maven repository.
- Remote, local, internal, or external repositories can be used to share plug-ins with any kind of license.
The Geronimo 1.1 Web Console provides a portlet that you can use to install or create Geronimo plug-ins at run time. To include a repository of your choice that searches for plug-ins, edit the attributes of the
DownloadedPluginRepos GBean, as shown in Listing 1.
Listing 1. Sample var\config\config.xml DownloadedPluginRepos GBean attributes
<gbean name="DownloadedPluginRepos"> <attribute name="repositoryList">http://people.apache.org/~ammulder/ plugin-repository-list-1.1.txt </attribute> <attribute name="userRepositories"> </attribute> <attribute name="downloadRepositories">[http://www.geronimoplugins.com/ repository/geronimo-1.1/] </attribute> </gbean>
To install a plug-in from another machine or repository, first update the repository list by clicking the link shown in Figure 1.
Figure 1. Install and remove a plug-in, then create portlet view
After you have the repository list, you can search for the plug-in you're looking for and install it. Also, using the same portlet shown in Figure 1, you can create a plug-in for any application or module running on your Geronimo server by clicking the Export Plugin button in the portlet. This opens a page where you provide the following information about the plug-in to be created:
- Human readable name
- Unique ID
- Line-separated list of repository for dependencies
- Category into which plug-in falls
- Short description
- Plug-in URL
- Author information
- Open source option
- Geronimo version
- JVM version
Provide the above information, and then save the plug-in.
Geronimo 1.1 brings a major restructuring of files -- namely all applications, services, and common libraries are now stored and unpackaged in a repository. A repository is nothing but a directory under your Geronimo installation. This repository has a strict internal structure defined by the moduleID of the module added into it. The moduleID in Geronimo 1.1 is composed of the following:
- Group ID: A name that identifies the group of a module. The default value is default.
- Artifact ID: A name of the module in a group. The default value is <file name>.
- Version: The version of module. The default value is <Numeric timestamp>.
- Type: The type of module, such as system module (car), jar module (jar), web archive (war), enterprise archive (ear), and so on. The default value is <File extension>.
A module is stored inside a repository as repository/groupId/artifactId/version/artifactId-version.type. This repository structure gives a more standardized and easily maintainable structure to Geronimo applications.
Another major difference in Geronimo 1.1 from the previous version is the introduction of deployment plans. As discussed in the repository section, a new element called moduleID has been introduced, replacing configID. The following sections outline the major elements that have been changed, removed from, or added into the Geronimo 1.1 deployment plan.
The elements of Listing 2 have been removed from the Geronimo Web plan in version 1.1.
Listing 2. Elements removed from the Geronimo Web plan
<context-priority-classloader> <sys:classloader-infoGroup> <Import: dependencyType> <dependencies: dependencyType> <hidden-classes> <non-overridableclasses> </sys:classloader-infoGroup> <configId> <parentId>
Listing 3. Elements added in the Geronimo Web plan
<environment <moduleId> <dependencies> :: All classloader and dependency information for the module <hidden-classes> :: A list of classes that will never be loaded from parent classloaders of this module <non-overridable-classes> :: A list of classes that will only be loaded from parent classloaders of this module <inverse-classloading> :: If the "inverse-classloading" element is specified, the standard classloading delegation model is to be reversed for this module. <suppress-default-environment> :: If the "suppress-default-environment" element is specified, then any default environment build by a builder when deploying the plan will be suppressed. </environment>
Another addition to the Geronimo Web plan is an optional reference to the Web container using an element, as shown in Listing 4.
Listing 4. Optional reference to the Web container using an element
<naming:web-container> <pattern> <groupId> <artifactId> <version> <module> <name> </pattern> <gbean-link> </naming:web-container>
In addition to incorporating all the changes defined in the Geronimo Web plan into the Geronimo Enterprise Application plan, the element <inverse-classloading>, which was in the geronimo-application 1.0 plan, has now been moved to the environment element.
The following elements of the Geronimo Client Application plan included in version 1.0 have been removed from version 1.1 and replaced with two separate client-environment and server-environment elements, as shown in Listing 5.
Listing 5. Client-environment and server-environment elements
<classloader-include-infoGroup> <import> <include> <dependency> <hidden-classes> <non-overridable-classes> </classloader-include-infoGroup> <configId> <parentId> <clientConfigId> <clientParentId>
Listing 6 shows the separate client-environment and server-environment elements.
Listing 6. Separate client-environment and server-environment elements:
<client-environment> <moduleId> <dependencies> <hidden-classes> <non-overridable-classes> <inverse-classloading> <suppress-default-environment> </client-environment> <server-environment> <moduleId> <dependencies> <hidden-classes> <non-overridable-classes> <inverse-classloading> <suppress-default-environment> </server-environment>
The remainder of the deployment plans, such as
openejb plan and
tomcat plan, incorporate the same changes as listed in the Web application plan.
Apache Geronimo 1.1 includes major enhancements to the Web Console as outlined in the following sections.
The server information portlet is now updated every two seconds with a server memory utilization graph, as shown in Figure 2.
Figure 2. Memory utilization graph view
You can get statistics, such as Pool Max, Lowest Recorded, Highest Recorded, and Threads in Use for all defined thread pools, as shown in Figure 3.
Figure 3. Thread Pools statistics view
This portlet can be used to configure the Apache 2 HTTP server using the mod_jk Apache module. Using this console module, you can define the delivery of static and dynamic content for each module separately. For each application running in Geronimo, you can specify whether the Web application should be exposed through Apache, whether Apache should serve static content for the Web application, and if Apache is serving static content, which URL paths should be passed to Geronimo (see Figure 4).
Figure 4. Mod_jk configuration wizard
The keystore manager wizard can be used to create keys to use with SSL connections. You can use this wizard to create new keystores and check the status of existing keystores. Figure 5 shows the keystore manager wizard.
Figure 5. The keystore manager wizard
This important enhancement to the Web Console was added to allow redeployment of applications using the Web Console.
The Geronimo hot deployer is an added service that allows deployment of applications at run time without using the deployment tool. Using the hot deployer service lets you make various changes to applications and their modules without having to stop the server and start it again. The hot deployer checks for changes in the deployment directory in your Geronimo installation and, if a new file, directory, or plan has been added, the hot deployer selects and deploys it, just as if you were deploying it manually using the deployment tool. If the module in the directory already exists, the changes will be redeployed, and if the files are removed, the hot deployer makes sure that the modules are undeployed. This feature was present in Geronimo 1.0, but was not working as desired. Following are the improved features of the Geronimo hot deployer:
- Tight synchronization between a directory and a deployed module; if files in a directory are deleted, deployed modules are undeployed. Similarly, if modules are undeployed, corresponding files in a deployment directory are also deleted.
- Modules are redeployed if files are changed.
- Hot deployment occurs during startup if new changes occurred when the server was down.
- Support is provided for service module deployment with a Geronimo plan file.
Note that undeployment during startup is still not supported.
Geronimo 1.1 supports a feature called in-place deployment, which means an archive or directory can be deployed without being copied into the Geronimo directory structure. You can do this using the
--inplace option with the deployment tool. This makes sure that nothing is replicated into your Geronimo directory structure and that files are picked from the location you specified. To use in-place deployment, unpack your archive into the directory of your choice and execute the following command:
deploy.bat --user system --inPlace deploy myApp.ear
Another deployment feature added to Geronimo 1.1 is the offline deployment option, which can be used to deploy any module when the server is not running. Internally, it loads the minimal required kernel and configuration modules before calling the deployer. The minimal required configurations loaded are listed in var/config/offline-deployer-list. To use offline deployment, you can use the
--offline flag with the deployment tool, as shown here:
deploy.bat --user system --offline deploy myApp.ear
The Eclipse plug-in provides integration between Geronimo and the Eclipse Web Tools Project (WTP). You can use this plug-in to develop, test, and debug your applications for Geronimo 1.1, and to create a Geronimo test environment within Eclipse. You can install the plug-in directly from within WTP, Version 1.5 by clicking the Don't see your server listed? link when defining a run time in WTP. Alternatively, the plug-in can also be installed via the update manager by creating a new remote site pointing to http://geronimo.apache.org/devtools. Figure 6 shows the Eclipse development and test environment for Geronimo 1.1.
Figure 6. The Eclipse plug-in and test environment
With the addition of a plug-in environment, Geronimo 1.1 opened a pathway for the inclusion of external applications, modules, and services. One such highly anticipated module was a portal application. Liferay Portal, available on Sourceforge.net, is an open source Java and J2EE portal system that helps organizations collaborate more efficiently by providing a consolidated view of disparate applications. (See Resources for a link to the Liferay portal plug-in.)
The Apache Geronimo application server is truly a community-based effort, and this article gave you a snapshot of features included in its newest version. In both the small- and medium-business domains, Geronimo is quickly becoming the application server of choice. The newly added plug-in feature further enhances the server's extensibility and ease of use. The Little-G with plug-in architecture gives you a flexible infrastructure to suit your own development requirements without the addition of extra memory or space in your environment. It's clear that the Geronimo development community has been successful in honing and polishing this project to make it especially well suited for a myriad of environments and users. Take Geronimo 1.1 for a spin -- and be sure to provide your input at the Apache Geronimo project site!
- Step up your Java application development with the Eclipse plug-in for Geronimo 1.1.
- Learn more about IBM WebSphere® Application Server Community Edition by reading articles and tutorials from the developerWorks WebSphere product section.
- Learn more about Geronimo, and get started using it now at the Apache Geronimo project resources area here on developerWorks.
- Check out the IBM Support for Apache Geronimo offering, which lets you develop Geronimo applications backed by world-class IBM support.
- Browse all the Apache articles and free Apache tutorials available in the developerWorks Open source zone.
- Browse for books on these and other technical topics at the Safari bookstore.
Get products and technologies
- Visit the Liferay Portal project area on SourceForge for more information about this portal project.
- Get extensions for Geronimo and repositories.
- Download a free binary and source version of Apache Geronimo 1.1.
- Build your next development project with IBM WebSphere Application Server Community Edition, available for download directly from developerWorks.
- Innovate your next open source development project with IBM trial software, available for download or on DVD.
- Participate in the discussion forum.
- Participate in Geronimo 1.1 JIRA discussions and threads.
- Get involved in the developerWorks community by participating in developerWorks blogs.
Rakesh Midha is a software architect with IBM Software Labs, Bangalore, currently working on IBM internal open source initiatives. He has eight years of technical experience in Java and C++ server-side programming on multiple platforms and various relational database systems like IBM DB2® Universal Database™, Oracle, MySQL, and Microsoft SQLServer. He is involved in number of J2EE applications, product architecture development, and implementation. He is an author of two DB2-related IBM Redbooks and a frequent author on IBM developerWorks. He presented a session titled "Inside Apache Geronimo 1.1 - What makes it special?" at ApacheCon Asia, Colombo Sri Lanka, in August 2006. He holds a bachelor's degree in electronics engineering from the Punjab University, Chandigarh, India.