Apache Geronimo: What We Tried and What Worked

Posted on By Luis Fernandez

GlassFish 3.1 just shipped with clustering, JBoss AS 6 is everywhere on mailing lists, and Tomcat holds steady for teams that want lean and fast. In the middle of that talk sits Apache Geronimo. We spent real cycles putting it through its paces on a couple of apps and promised to write down what we tried and what actually worked. If you are choosing a Java server this week, this is the field note version, no brochure talk.

Definitions

Apache Geronimo is a Java EE server from the Apache folks. It is modular, so you can pick a build that uses Tomcat or Jetty for the web container. It ships with ActiveMQ for messaging, OpenEJB for EJBs, and OpenJPA for JPA. You get an Admin Console on the web and a command line called GShell. Deployments can use standard archives and also Geronimo specific deployment plans when you want to wire resources in a repeatable way.

You will see terms like assembly which is a particular packaging of the server, and CAR files which are server modules you can add. Think of it as a stack that can shrink or grow. If you prefer one servlet engine over the other, Geronimo lets you decide up front.

Examples

We ran two tracks. One was a classic WAR with Spring MVC and JPA. The other was an EAR with EJB 3 session beans, JMS, and a couple of scheduled jobs. Here is what worked without drama.

  • Install and start. The Tomcat build of Geronimo 2.2.1 booted clean on a stock JDK 6. The startup logs are readable and the default ports are friendly. No surprises there.
  • Admin Console. The web console let us add JDBC pools for MySQL and Oracle using the wizard. We tested XA and non XA and both registered fine. The console also made it easy to check JNDI names so the team could line up config with code.
  • JMS with ActiveMQ. Creating queues and topics from the console was quick. Message driven beans consumed messages right away. We pushed a small load test and the broker kept up on a single node.
  • Security realms. We wired an LDAP realm for auth and a simple properties realm for local logins. Mapping to web roles in web.xml worked as expected. Form login behaved exactly like on Tomcat.
  • Web services. With the CXF bits installed we published a basic SOAP endpoint and called it from SoapUI. No ceremony. The default handlers were enough for our needs.
  • Hot deploy. Dropping a WAR into the deploy folder triggered an auto deploy in seconds. For day to day testing that saved us time. For the EAR we used the deploy command to get clearer feedback.
  • Classloading sanity. When we kept our libs inside the app and did not leak shared jars into the server, things stayed stable. JPA booted clean, and OpenJPA had no problem with our entities.

We also tried the Jetty build to see startup and memory. It did start a bit quicker and used a little less RAM on our small instance, but for the team that lives in Tomcat land the Tomcat build felt natural. Both handled SSL with the same keystore config we already had.

Counterexamples

It was not all smooth. A few edges showed up in real work.

  • Java EE 6 story. If you want CDI and the very latest APIs, this is not fully there yet in the stable line. Our EJB 3 needs were fine, but friends chasing CDI felt more at home on GlassFish right now.
  • Logging clashes. We hit a small fight between commons logging in the server and in our app. The fix was easy remove the duplicate from our WAR but the error messages were not obvious the first time.
  • Plugin catalog. The plugin repo inside the console looks a bit dusty. We ended up installing a few things by hand rather than clicking around for a while.
  • GBean errors. When a deploy plan has a typo the stack traces talk GBeans and services. If you are new to Geronimo that language can slow you down. After two or three fixes you get the hang of it.
  • Clustering. There is no simple switch for farm deploy and full session replication. If that is a must for you, weigh that part early.
  • Admin Console speed. With many resources defined, the console felt sluggish on a tiny VM. Scripted deploys with a couple of commands were faster and more repeatable for us.

Decision rubric

If you need a quick call on whether to pick Apache Geronimo for your project, walk this list and be honest about your team and your needs.

  • Target spec level. If you must have full Java EE 6 features like CDI today, lean to GlassFish 3.1. If Java EE 5 with EJB 3 and JPA covers your scope, Geronimo is in range.
  • Preferred web container. If your ops team already knows Tomcat, the Tomcat build of Geronimo is a friendly path. If you want the small and nimble vibe of Jetty, that build is solid too.
  • Messaging first. If ActiveMQ is central in your design, the default pairing inside Geronimo is handy. Fewer moving parts and less glue.
  • Team experience. If your devs know deployment plans and JNDI by heart, you will enjoy the control. If your team favors a click and done workflow, GlassFish and JBoss give you a smoother ride.
  • Operations comfort. If you want open, readable configs and the ability to trim the server, Geronimo is nice. If you need polished cluster tooling right now, look at the other two big names.
  • Vendor path. If you plan to move toward WebSphere Community Edition at some point, Geronimo lines up well since they share roots.
  • Ecosystem and docs. Community forums answer most questions, but the freshest docs are not always the easiest to find. If your team leans on docs every day, check that comfort level first.

Lessons learned

  • Start simple. Pick the Tomcat build unless you have a strong reason to go Jetty. Fewer choices means more progress on day one.
  • Invest in deployment plans. Write them early and keep them in source control. They remove guesswork when you move from laptop to test to prod.
  • Keep jars inside the app. Avoid shared libs in the server unless you really need them. This kept classloading clean for us.
  • Use portable JNDI names. Give resources clear names and stick to them. Moving the same EAR between servers got easier once we did this.
  • Script the boring parts. The deploy command, a couple of properties files, and you have repeatable builds. The console is fine for the first try, scripting is better for the tenth.
  • Version pinning matters. Lock your driver versions and any server plugins you add. Surprises came from version drift, not from Geronimo itself.

Bottom line from our tests. Apache Geronimo is a capable server that rewards you if you like control and the Apache stack. If you want the newest Java EE features and sweet cluster tools out of the box, pick GlassFish or JBoss for now. If your app needs ActiveMQ, OpenEJB, and a Tomcat feel with a real admin console, Geronimo is a nice fit. We are keeping it in our short list and we would ship a project on it without losing sleep.

Software Architecture Software Engineering