[jboss-cvs] JBossAS SVN: r78588 - projects/demos/microcontainer/trunk/docs.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue Sep 16 09:13:43 EDT 2008
Author: alesj
Date: 2008-09-16 09:13:43 -0400 (Tue, 16 Sep 2008)
New Revision: 78588
Modified:
projects/demos/microcontainer/trunk/docs/models.txt
Log:
Commit current wiki version.
Modified: projects/demos/microcontainer/trunk/docs/models.txt
===================================================================
--- projects/demos/microcontainer/trunk/docs/models.txt 2008-09-16 13:08:13 UTC (rev 78587)
+++ projects/demos/microcontainer/trunk/docs/models.txt 2008-09-16 13:13:43 UTC (rev 78588)
@@ -1,17 +1,19 @@
-JBoss Microcontainer - Component models
+__bold__ means it needs to be fixed
-[Intro]
+!!JBoss Microcontainer - Component models
-Looking at the current state of Java, we can see that POJOs rule the land again.
-Its dominance straches from enterprise apps to middleware services.
-At JBoss we were known for our modular JMX based kernel, a bunch of flexible MBeans were constructing our MicroKernel.
-But as the tide was about to change, we still wanted to be ahead of the big wave. Hence the Microcontainer project was born.
+!Introduction
-Microcontainer project is about many things.
+Looking at the current state of Java, we can see that POJOs (1) rule the land again.
+Its dominance stretches from enterprise apps to middleware services. At JBoss we were known for our modular JMX (2) based kernel (3). Application server was nothing more than a bunch of flexible MBeans (2) and a powerful MicroKernel in the middle.
+But, as you could feel the change is coming, we still wanted to be ahead of the pack. Hence the Microcontainer project was born.
+
+The JBoss Microcontainer (4) project is about many things.
+Just to name a few, Microcontainer's puzzles are ranging from reflection abstraction, virtual file system, simple state machine and all the way to transparent AOP integration, new classloading layer, deployment framework, OSGi framework implementation.
I'll try to address them all over a small series of articles here at DZone.
-This, first one, being about Microcontainer's component models.
+This, the first one, being about Microcontainer's component models.
-[What is component model]
+!What is a component model
What do we consider component model?
First we need to determine what is our component.
@@ -19,131 +21,323 @@
Previously mentioned JMX MBeans is one of them.
MBeans being components, and its interactions are executing mbean operations,
-referencing attibutes, setting attributes and declaring explicit dependecies between named mbeans.
+referencing attributes, setting attributes and declaring explicit dependencies between named mbeans.
-But, as mentioned, we had that already with MicroKernel.
-So as expected, Microcontainer brings extensive POJO support.
-As default behavior / interactions in Microcontainer you get what you normally get from IoC containers,
-smililar to MBeans, operations are plain method invocations, attributes are setters/getters and explicit dependecies are still present.
-Having only that would mean we didn't get much further than just releaving the pain of declaring MBeans, hence it's only logical to expect something more.
+As mentioned, we had that already with MicroKernel.
+And as expected, Microcontainer brings extensive POJO support.
+Default behavior / interactions in Microcontainer is what you also normally get from any other IoC (5) container,
+similar to MBeans, operations are plain method invocations, attributes are setters/getters and explicit dependencies are still present.
+Having only that would mean we didn't get much further than just relieving the pain of declaring MBeans, hence it's only logical to expect something more.
Since there is many new interesting features that we introduced, but this article is more about introduction to different component model interaction, I'll leave that for the next article in the series.
OK, so far we have MBeans and our custom POJOs.
-But currently there is many existing POJO component models out there, Guice and Spring being among the most popular.
-Hence we wanted to have nice integration with those two as well.
+Currently there is many existing POJO component models out there, Guice (6) and Spring (7) being among the most popular. Having nice integration with those was also one of our important goals.
-[Demo environment setup]
+!Demo environment setup
Let's now turn to our demo.
-In order to get a slight feeling for how demos work, I'll describe parts that constitute the demos.
+In order to get a slight feeling for how demo works, I'll describe parts that constitute the demo.
-All source code can be found at this location of our SVN repository:
- - http://anonsvn.jboss.org/repos/jbossas/projects/demos/trunk/
+All source code can be found at this location of our Subversion repository:
+* http://anonsvn.jboss.org/repos/jbossas/projects/demos/microcontainer/trunk/
Project is fully mavenized, so it should be easy adjust it to your IDE.
-Let's just quickly go over the modules that make this article's demo and decribe it's usage.
-Once we're fully over the series of articles we can have a more detailed look at what certain module does.
+Let's just quickly go over the sub-projects that make this article's demo and describe it's usage.
+Once we're fully over the series of articles we can have a more detailed look at what certain sub-project does.
-JBoss Microcontainer Demos modules relevant for this article:
- - boostrap (as the name suggest, it bootstraps Microcontainer for demo code)
- - jmx (adds the JMX notion to demo's bootstrap)
- - models (source code of our components / services)
+JBoss Microcontainer Demos, sub-projects relevant for this article:
+* bootstrap (as the name suggest, it bootstraps Microcontainer with demo code)
+* jmx (adds the JMX notion to demo's bootstrap)
+* models (source code of our components / services)
The demo has only one variable you need to set - demos home - but even this one can be optional if you checked-out your project into \projects\demos directory.
Else you need to set system property demos.home (e.g. -Ddemos.home=<my demos home>).
-If all is right, you should be now able to run JMXMain class as a main class.
-Make sure you include models module classpath, since some of the services require additional classes on the classpath, a bit more then what jmx module expects.
+If all is right, you should now be able to run JMXMain class as a main class.
+Make sure you include models sub-project classpath, since some of the services require additional classes on the classpath, a bit more then what jmx sub-project expects.
Once Microcontainer is booted it starts to scan ${demos.home}/sandbox directory for any changes.
Now all we need is to provide a deployable unit and drop it there.
-[Models]
+!Models
-And this is what our models module is all about. You can quickly try if everything is in place, by building models module (mvn package) and drop it into the sandbox.
-You should get some nice errorless output on the console else something went wrong.
+And this is what our models sub-project is all about. You can quickly try if everything is in place, by building models sub-project (mvn package) and drop it into the sandbox.
+You should get some nice error-less output on the console otherwise something went wrong.
-OK, but lets first go over what exactly does this models module do, where is the integration code and then try deploying it once again.
+OK, but lets first go over what exactly does this models sub-project do, where is the integration code and then try deploying it once again.
-If we look at the models src/main/resources/META-INF directory, we'll see plenty of -beans.xml resource files there and one -service.xml.
-Each one of them with meaningful name matching source code package from models's src/main/java/org/jboss/demos/models.
+If we look at the models src/main/resources/META-INF directory, we'll see plenty of -beans.xml resource files and one -service.xml.
+Each with meaningful name matching source code package from models's src/main/java/org/jboss/demos/models.
-Lets disect them one by one. Starting at the one's that have no dependecies.
+Let's dissect them one by one. Starting at the one's that have no dependencies.
-<plain-beans.xml>
+{{{
+<deployment xmlns="urn:jboss:bean-deployer:2.0">
+
+ <bean name="PlainPojo" class="org.jboss.demos.models.plain.Pojo"/>
+
+ <beanfactory name="PojoFactory" class="org.jboss.demos.models.plain.Pojo">
+ <property name="factoryClass">org.jboss.demos.models.plain.PojoFactory</property>
+ </beanfactory>
+
+</deployment>
+}}}
-This is a simple Micrcocontainer beans descriptior file. Anyone who crossed paths with some IoC should be familiar with it.
+This is a simple Micrcocontainer beans descriptor file. Anyone who crossed paths with some IoC should be familiar with it.
And, as I already mentioned, I'll follow up on more advanced usage in the next article.
I mentioned nice Spring integration, this next file shows what we have done.
-<spring-beans.xml>
+{{{
+<beans xmlns="urn:jboss:spring-beans:2.0">
-As you can see, file's namespace is different from previous Microcontainer beans plain-beans.xml file.
+ <!-- Adding @Spring annotation handler -->
+ <bean id="SpringAnnotationPlugin" class="org.jboss.spring.annotations.SpringBeanAnnotationPlugin" />
+
+ <bean id="SpringPojo" class="org.jboss.demos.models.spring.Pojo"/>
+
+</beans>
+}}}
+
+Note that file's namespace is different from previous Microcontainer beans plain-beans.xml file.
urn:jboss:spring-beans:2.0 namespace points to our version of Spring schema port,
meaning you can describe your beans Spring style, but it's the Microcontainer that's gonna deploy then, not Spring's bean factory notion.
-<Spring Pojo>
+{{{
+public class Pojo extends AbstractPojo implements BeanNameAware
+{
+ private String beanName;
+ public void setBeanName(String name)
+ {
+ beanName = name;
+ }
+
+ public String getBeanName()
+ {
+ return beanName;
+ }
+
+ public void start()
+ {
+ if ("SpringPojo".equals(getBeanName()) == false)
+ throw new IllegalArgumentException("Name doesn't match: " + getBeanName());
+ }
+}
+}}}
+
Although SpringPojo bean has a dependency on Spring lib, but it's only there to expose we can even mock some of the Spring's callback behavior,
see SpringBeanAnnotationPlugin for more details, w/o having Spring lib in Microcontainer's classpath.
-Since we introduced Spring integration, lets have a look at Guice integration.
+Since we introduced Spring integration, let's have a look at Guice integration.
As Guice users know, Guice is all about types matching. Configuration of Guice beans is done via Modules.
-So, in order to provide beans, one most implement a Module.
+Meaning, in order to provide beans, one most implement a Module.
-<guice-beans.xml>
+{{{
+<deployment xmlns="urn:jboss:bean-deployer:2.0">
+ <bean name="GuicePlugin" class="org.jboss.guice.spi.GuiceKernelRegistryEntryPlugin">
+ <constructor>
+ <parameter>
+ <array elementClass="com.google.inject.Module">
+ <bean class="org.jboss.demos.models.guice.PojoModule"/>
+ </array>
+ </parameter>
+ </constructor>
+ </bean>
+
+</deployment>
+}}}
+
Two important parts to watch from this file are PojoModule and GuiceKernelRegistryEntryPlugin.
The first one is where we configure our beans
-<PojoModule>
+{{{
+public class PojoModule extends AbstractModule
+{
+ private Controller controller;
+ @Constructor
+ public PojoModule(@Inject(bean = KernelConstants.KERNEL_CONTROLLER_NAME) Controller controller)
+ {
+ this.controller = controller;
+ }
+
+ protected void configure()
+ {
+ bind(Controller.class).toInstance(controller);
+ bind(IPojo.class).to(Pojo.class).in(Scopes.SINGLETON);
+ bind(IPojo.class).annotatedWith(FromMC.class).toProvider(GuiceIntegration.fromMicrocontainer(IPojo.class, "PlainPojo"));
+ }
+}
+}}}
+
where the second one is where the integration with Microcontainer lies
-<GuiceKernelRegistryEntryPlugin>
+{{{
+public class GuiceKernelRegistryEntryPlugin implements KernelRegistryPlugin
+{
+ private Injector injector;
+ public GuiceKernelRegistryEntryPlugin(Module... modules)
+ {
+ injector = Guice.createInjector(modules);
+ }
+
+ public void destroy()
+ {
+ injector = null;
+ }
+
+ public KernelRegistryEntry getEntry(Object name)
+ {
+ KernelRegistryEntry entry = null;
+ try
+ {
+ if (name instanceof Class<?>)
+ {
+ Class<?> clazz = (Class<?>)name;
+ entry = new AbstractKernelRegistryEntry(name, injector.getInstance(clazz));
+ }
+ else if (name instanceof Key)
+ {
+ Key<?> key = (Key<?>)name;
+ entry = new AbstractKernelRegistryEntry(name, injector.getInstance(key));
+ }
+ }
+ catch (Exception ignored)
+ {
+ }
+ return entry;
+ }
+}
+}}}
+
See how we create Injector from Modules and then do lookup on it for matching beans.
In mbeans-service.xml we declare legacy usage of MBean.
-<mbeans-service.xml>
+{{{
+<server>
+ <mbean code="org.jboss.demos.models.mbeans.Pojo" name="jboss.demos:service=pojo">
+ <attribute name="OtherPojo"><inject bean="PlainPojo"/></attribute>
+ </mbean>
+
+</server>
+}}}
+
Interesting bit to detect here is injection of plain POJO into MBean.
By that introducing our first different component models interaction. Yay!
In order to allow for MBean deployment via Microcontainer, a whole new component model handling code had to be written.
-See system-jmx-beans.xml for more details. The code from this file lives in JBossAS source code: system-jmx module.
+See system-jmx-beans.xml for more details. The code from this file lives in JBossAS source code: system-jmx sub-project.
One note here, this is currently only possible with JBoss's JMX implementation, since system-jmx code uses some implementation details.
-OK, we already deployed MBeans, but what about if we want to expose existing POJO also as MBeans, registering into a mbean server.
+OK, we already deployed MBeans, but what about if we want to expose existing POJO also as MBeans, registering them into a mbean server.
-<jmx-beans.xml>
+{{{
+<deployment xmlns="urn:jboss:bean-deployer:2.0">
+ <bean name="AnnotatedJMXPojo" class="org.jboss.demos.models.jmx.AtJmxPojo"/>
+
+ <bean name="XmlJMXPojo" class="org.jboss.demos.models.mbeans.Pojo">
+ <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(exposedInterface=org.jboss.demos.models.mbeans.PojoMBean.class, registerDirectly=true)</annotation>
+ </bean>
+
+ <bean name="ExposedPojo" class="org.jboss.demos.models.jmx.Pojo"/>
+
+ <bean name="AnnotatedExposePojo" class="org.jboss.demos.models.jmx.ExposePojo">
+ <constructor>
+ <parameter><inject bean="ExposedPojo"/></parameter>
+ </constructor>
+ </bean>
+
+</deployment>
+}}}
+
Doing that, as you can see from looking at any of the beans in this file, is as simple as annotating beans with @JMX annotation.
You can either expose bean directly or even its property.
-<security-beans.xml>
+{{{
+<deployment xmlns="urn:jboss:bean-deployer:2.0">
+ <bean name="XMLLoginConfig" class="org.jboss.demos.models.old.XMLLoginConfig"/>
+
+ <bean name="SecurityConfig" class="org.jboss.demos.models.old.SecurityConfig">
+ <property name="defaultLoginConfig"><inject bean="XMLLoginConfig"/></property>
+ </bean>
+
+ <bean name="SecurityChecker" class="org.jboss.demos.models.old.Checker">
+ <property name="loginConfig"><inject bean="jboss.security:service=XMLLoginConfig"/></property>
+ <property name="securityConfig"><inject bean="jboss.security:service=SecurityConfig"/></property>
+ </bean>
+
+</deployment>
+}}}
+
Here we can see how you can use any of the injection mechanisms, injecting plain pojo or from mbean server.
One of the injection options is also to use type injection also sometimes called autowiring.
-<injection-beans.xml>
+{{{
+<deployment xmlns="urn:jboss:bean-deployer:2.0">
+ <bean name="FromGuice" class="org.jboss.demos.models.plain.FromGuice">
+ <constructor><parameter><inject bean="PlainPojo"/></parameter></constructor>
+ <property name="guicePojo"><inject/></property>
+ </bean>
+
+ <bean name="AllPojos" class="org.jboss.demos.models.plain.AllPojos">
+ <property name="directMBean"><inject bean="jboss.demos:service=pojo"/></property>
+ <property name="exposedMBean"><inject bean="jboss.demos:service=ExposedPojo"/></property>
+ <property name="exposedMBean"><inject bean="jboss.demos:service=ExposedPojo"/></property>
+ </bean>
+
+</deployment>
+}}}
+
FromGuice bean gets Guice bean injected via type matching, where PlainPojo is injected with common name injection.
We then test if Guice binding works as expected:
-<FromGuice>
+{{{
+public class FromGuice
+{
+ private IPojo plainPojo;
+ private org.jboss.demos.models.guice.Pojo guicePojo;
+ public FromGuice(IPojo plainPojo)
+ {
+ this.plainPojo = plainPojo;
+ }
+
+ public void setGuicePojo(org.jboss.demos.models.guice.Pojo guicePojo)
+ {
+ this.guicePojo = guicePojo;
+ }
+
+ public void start()
+ {
+ if (plainPojo != guicePojo.getMcPojo())
+ throw new IllegalArgumentException("Pojos are not the same: " + plainPojo + "!=" + guicePojo.getMcPojo());
+ }
+}
+}}}
+
This only leaves us with alias component model.
Even though alias is quite trivial feature, in order to implement it as true dependency,
it has to be introduced as a new component model inside Microcontainer.
-Implemetation details are part of AbstractController source code.
+Implementation details are part of AbstractController source code.
-<alias-beans.xml>
+{{{
+<deployment xmlns="urn:jboss:bean-deployer:2.0">
+ <alias name="SpringPojo">springPojo</alias>
+
+</deployment>
+}}}
+
Here we map SpringPojo name to springPojo alias.
-The beauty of having alias as true compoment model is that it doesn't matter when real bean is deployed.
+The beauty of having alias as true component model is that it doesn't matter when real bean is deployed.
Meaning alias will wait in non-installed state until real bean triggers it.
We're done!
@@ -157,3 +351,12 @@
An example of this is the upcoming OSGi services, but that's another story, another article.
Stayed tuned for detailed Microcontainer IoC article.
+
+References:
+* (1) POJO - Plain Old Java Object
+* (2) JMX - Java Management Extension [http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/]
+* (3) Kernel - [http://en.wikipedia.org/wiki/Kernel_(computer_science)]
+* (4) Microcontainer - [http://www.jboss.org/jbossmc]
+* (5) IoC - [Inversion of Control|http://en.wikipedia.org/wiki/Inversion_of_control]
+* (6) Guice - [http://code.google.com/p/google-guice/]
+* (7) Spring - [http://www.springframework.org]
More information about the jboss-cvs-commits
mailing list