History
The GBean project was founded one sunny afternoon a Los Angeles Starbucks. Alan Cabrera, David Blevins, Hiram Chirino, James Strachan, Jason van Zyl, Rob Davies and myself all happened to be in town, so I decided to demo my super-secret side-project; a Spring-based, JSR-77 compliant, kernel with optional automatic JMX exporting...but that's jumping ahead a little.
Rod Johnson and Spring Team
I had only briefly meet Rod Johnson before the 2005 Server Side Symposium. When I went to the conference one of my big goals was to try to come up with a better design for the Geronimo Spring integration module. This module was written by Jules Gosnell and Rob Harop, but suffered from integration that was less then optimal. Due to design constraints imposed by the Geronimo Kernel the integration required odd things such as proxying proxies.
I spend a lot of time with the entire Spring team swapping IoC container designs, configuration issues, and just hanging out drinking coffee and then copious beers. On the second day of the conference, I attended "Advanced Spring Framework" by Rod Johnson. At the time I knew very little about Spring other then everyone was asking for integration. Just about every feature of the Spring framework Rod demonstrated, I found myself saying, "wow that is cool, I need to copy that". They had features like infinitely nestable services, service factories, flexible collection support, abstract services and stuff they were going to implement such as domain specific xml configuration.
About half way through the session, I sat back and thought to myself, why copy every feature of Spring instead of just using Spring. After, the presentation I pulled aside Rob Harop (Rod was just swarmed), and asked him what he thought about building an extension of the Spring Framework to do JSR-77 compliant management and lifecycle support for a long running server. It just made sense. Spring is not a server, nor does it want to be, it relies on having a server environment in which to operate, and my expertise was building just this kind of environment. That night I downloaded the Spring code and started playing around with how Spring could be part of a server rather than just live in one.
The Discovery
Over the few weeks in between Geronimo J2EE test runs, nights and weekends, I played with Spring. I focused on learning Spring from a users perspective and learning the Spring code base. Ultimately, I wanted to add support for JSR-77 style management and the concept of a long-lived server, and this turned out to be a much bigger undertaking then I first thought. Spring is designed to support a single application within an already existing server. Therefore Spring does not manage class loaders, nor does it have a standardized way to load and unload applications. The largest overall problem is Spring does not manage individual services, but instead manages the life cycle of entire applications as a single granular unit.
After much experimentation, I discovered I could load the spring.xml configuration into memory and then effectively split that spring.xml file into one spring.xml for each bean. Then I could use the existing Spring code to start and stop my mini-applications containing a single bean. Once I had this working, a flood of new issues appeared such as managing class loaders and resolving bean references across the mini-applications. Once I got by these and many more issues, the next problem was how to prove the implementation.
The Proof
Given my background in Geronimo, I decided to try to plug the new Spring system directly into the Geronimo kernel. The idea was if I could get that working, I could exercise the Spring code by running the Geronimo unit tests and the J2EE test suite. I started by jamming a porting layer directly into the Geronimo kernel that converted all Geronimo services to Spring services.
This proved to be a huge undertaking. The problem is not that Geronimo and Spring are fundamentally different; it is that they are subtly different. For example, Geronimo assumes that the class loader is only known when the configuration starts while Spring assumes that the class loader is know when the original configuration file is loaded into memory. Geronimo is much more forgiving when working with Java classes that don't strictly follow the Java Beans specification and Spring simply throws an exception. After much tweaking of the porting layer, I could run the Geronimo build, the J2EE test suite, and work with native Spring services.
The Decision
I decided it was time to show the code to a few close friends. I was a bit unsure of this, though. About a year and a half earlier, while working on a Tomcat integration for Geronimo, I actually ended up writing a new Servlet engine. After talking with a few people, I decided to shelve the Servlet engine; given that we already have two great open source Servlet engines, this would have just been a distraction to the whole community. I could see the same issue with this code, but shelving it didn't seem like the best choice either.
The Gang (Simula, Logic Blaze and Megere)
David Blevins and I went down to the office in El Segundo. At the time, the Gluecode office was in the same building as Simula Labs, Logic Blaze, and Megere, and the entire team was in town for some event. We all piled into a conference room and I began showing them the proof of concept.
As I walked the guys through the code, I was surprised at the response. The features I thought were most important, they didn't seem to care to much about, but the stuff I really added as an after thought they were very excited about.
Rob and Alan were really excited about the ability to automatically export POJOs to JMX. Both of them had been struggling with the JMX APIs in their company projects.
James liked the Spring support but wanted to make it optional. In most cases, he wanted to use Spring, but in some embedded systems, he wanted to hand wire the objects and still be able to use the other features.
David and Jason wanted backwards compatibility and interoperability. David primarily for bridging between the OpenEJB 1.x service model, Spring, and Geronimo services. Jason wanted to make sure that it worked with his IoC container Plexus.
Basically, they wanted all of the features available to any framework whether it is Spring, Plexus, OpenEJB, or hand wired POJOs. After short discussion, we decided to found the GBean project at Codehaus to create an IoC independent server for OpenEJB, ActiveMQ, and the other million Strachan projects.
By the time I arrived the next day, James had already created the project at Codehaus and was hacking some metadata code for the JMX integration. The initial revision was very rough, and relied on a private fork of Spring.
The Demonstration
The next week was spent cleaning up and organizing the code so the other guys could start working on the project. At the same time a fairly heated discussion was started on Geronimo mailing list about difficulties of using a serialization based configuration system.
Since the GBean server was completely backwards compatible with Geronimo services and even had an implementation of the Geronimo kernel, I decided to quickly whip together a version of the GBean server that booted and acted like the Geronimo server. I checked in the geronimo/sandbox/spring-assembly and announced the integration on May 17, 2005 and asked people to try it out and give some feedback.
Today
Since that announcement, continued feedback from The Gang and more tinkering with Spring has eliminated the need for a forked version of Spring, and vastly simplified the entire code base. The project is still very much experimental and a work in progress. Since this code is by definition core to any project that adopts it, we are working slowly and carefully to integrate the code base into the other projects.
-Dain Sundstrom