This is old news, but we never really made any noise about it so I thought I should blog about it. Adrian Brock has completed version 1.0 (and 1.0.1) of the JBoss Microcontainer. Adrian actually prefers to do real work than blog, so he left this job to me, JBoss's Chief Marketect.

JBoss Microcontainer is a complete Inversion of Control, Dependency Injection lightweight container. It allows you to configure POJOs through XML and has lifecycle for these POJOs as well so that they can be treated as services. It does not require the JBoss Application Server to use and can be used in any application whether it be a J2EE app or a plain Java ap.

The JBoss Microcontainer starts JBoss on an evolution to embeddable Java EE. The idea is that all JBoss Java EE and JEMS services will be embeddable and runnable in environments outside of the JBoss Application Server including: JUnit tests, Swing applications, standalone Tomcat, and even other vendor application servers. If you have downloaded JBoss Seam or JBoss Embeddable EJB 3.0 you are already using the JBoss Microcontainer as it is being used to initialize and configure basic services used by these frameworks like a transaction manager, JNDI, JCA-based datasources, and JMS. Over the next few months and quarters you will see more and more JBoss services be converted into POJOs and configurable and usable in non-app-server environment. This will culminate with the release of JBoss 5 sometime in 2006.

The first version of the JBoss Microcontainer is just a plain, but advanced, IoC container. Later versions will allow you to layer additonal kernel-like services like advanced classloading through our Unified Class Loader architecture, as well as a rewrite of JBoss Deployers so that you can package and deploy your components and have them be loaded and bootstrapped by the Microcontainer. Currently though, here's some features that I think are simple, but pretty cool.

• Complete property and constructor dependency injection.
• Support for lists, maps, sets.
• Services on demand. Basically, a declared POJO will not be allocated or initialised until it is referenced. This is similar in idea to the Microsoft Services Manager where you can disable, enable, or provide automatic startup of various services.
• A complete state machine. A POJO/service will not be initialized until all of its dependencies have gone through their lifecycle. This state machine is pluggable.
• Define dependencies based on the state of the referenced dependency. This allows you to handle certain cases like circular dependencies.
• Construction based on factory methods. When creating a bean, you can have it be created by calling a static method or member method of an existing bean. The container doesn't always have to be responsible for allocating the instance of the bean.
• Pluggable XML. You can plug in your own schema's that do your own definition of property values. (not yet documented).

So why is JBoss creating its own IoC container when there are a bunch of other frameworks out there that do similar things? Well, to be brief, it would be suicide for us to depend on a third party to provide such a core piece of our infrastructure. For basic IoC, this doesn't really matter, but when we start to layer things like classloading, packaging, deployment, and most importantly management, this will become more and more important to us. Really, JBoss Microcontainer was written as the next iteration of the old JBoss JMX Microkernel so that we could evolve the JBoss Application Server. So, JBoss MC's primary customer is JBoss 5 AS, JBoss Seam, and Embeddable EJB 3.0. JBoss Microcontainer is there for you the community to use if you are interested in it which is why we are calling attention to it and promoting it a little.

Anyways, check it out. Adrian write some pretty high quality code and I have learned a lot from him over the past years. If you didn't know already, Adrian also maintains and leads our current JCA, JTA, and JMS implementation as well, so he's a pretty busy (and talented) guy. Great work Adrian!

Bill