The JBoss Microcontainer provides an environment to configure and manage POJOs (plain old java objects). It is designed to reproduce the existing JBoss JMX Microkernel but targeted at POJO environments. As such it can be used standalone outside the JBoss Application Server.
As we mention JBoss Application Server, while rewriting its Microkernel to a POJO environment, there were other aspects that also needed to be considered while changing the core functionality. New modules or subprojects were introduced to the Microcontainer project to tightly integrate those aspects with the new POJO approach and to eventually solve some of the basic problems that arose over the years with the changes application server went through. We will discuss these modules and subproject later on.
At its core, the JBoss Microcontainer is a generic "dependency injection" framework. Its primary function is to instantiate objects, figure out their dependencies (e.g., object A must be instantiated before object B), and then manage the relationship between those objects (e.g., object A is a property of object B). With the JBoss Microcontainer, you can build applications or shared services using simple POJOs. The JBoss Microcontainer is responsible for assembling the POJOs together according to an externally defined XML configuration file. It decouples the components in an application and makes the application easy to unit-test.
The JBoss Microcontainer is a big object factory that manages objects. In this sense, it is similar to existing dependency injection frameworks such as the Spring framework and HiveMind framework. However, JBoss Microcontainer also has several important new features that sets it apart from existing frameworks.
JBoss Microcontainer supports life cycles for POJO components. It gives you fine-grained control over exactly how the objects are created, instantiated, and destroyed.
JBoss Microcontainer manages dependencies between objects. For instance, you can declare that object A must be instantiated before object B can be created.
JBoss Microcontainer integrates with the JBoss AOP (Aspect Oriented Programming) framework. In the JBoss Microcontainer configuration file, you can easily wire aspects as services to POJOs.
JBoss Microcontainer is used as a replacement for the JMX-based Microkernel in JBoss AS 5.x and above. All the existing features of MBeans are thightly integrated into new Microcontainer based ServiceController.
JBoss Microcontainer is embedded in JBoss AS 4.x. It is the ideal choice if you need to develop shared services in JBoss AS.
Of course, you can also run JBoss Microcontainer outside of the JBoss AS. For instance, you can run it in a Java SE (e.g., Swing) application or in the Tomcat servlet container. So, JBoss Microcontainer primarily targets three types of developers.
Framework developers can use JBoss Microcontainer to assemble custom server frameworks. For instance, the JBoss embeddable EJB3 framework is based on the Microcontainer.
JBoss application developers can develop POJO services that nicely integrate into the server and can be shared across applications.
Application developers can write lightweight applications that makes use of services from a variety of sources (e.g., transaction service from JBoss, persistence service from Hibernate, and HTTP service from Tomcat).
A typical JBoss Microcontainer application or service include a set of POJOs that complete business tasks,
as
well as an XML configuration file called
META-INF/jboss-beans.xml
on the class path. The
jboss-beans.xml
file tells the JBoss Microcontianer how to assemble those POJOs together. For deployment, you can JAR the POJO
classes, as well as the
META-INF/jboss-beans.xml
file together in a simple .jar archive file (see
Chapter 5, Packaging
).
This document takes you through some example deployments into JBoss Microcontainer 2.0 explaining how to configure POJOs and link them together through injection. We will also explain how to use other Microcontainer modules inside JBoss AS 5.x, especially the re-written deployers and classloader modules. Later, we will discuss how to do the same thing outside the application server.