[jboss-cvs] JBossAS SVN: r78545 - in projects/demos/trunk: docs and 1 other directory.

[jboss-cvs-commits at lists.jboss.org]

Author: alesj
Date: 2008-09-15 11:04:41 -0400 (Mon, 15 Sep 2008)
New Revision: 78545

Added:
   projects/demos/trunk/docs/
   projects/demos/trunk/docs/models.txt
Log:
Initial article brain dump.

Added: projects/demos/trunk/docs/models.txt
===================================================================
--- projects/demos/trunk/docs/models.txt	                        (rev 0)
+++ projects/demos/trunk/docs/models.txt	2008-09-15 15:04:41 UTC (rev 78545)
@@ -0,0 +1,147 @@
+JBoss Microcontainer - Component modules 
+
+[Intro]
+
+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.
+
+Microcontainer project is about many things.
+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.
+
+[What is component model]
+
+What do we consider component model?
+First we need to determine what is our component.
+To consider that a model, we need to declare what kind of interactions we allow.
+
+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.
+
+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.
+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.
+
+[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.
+
+All source code can be found at this location of our SVN repository:
+ - http://anonsvn.jboss.org/repos/jbossas/projects/demos/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.
+
+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)
+ 
+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.
+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]
+ 
+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.
+
+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.
+ 
+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.
+ 
+Lets disect them one by one. Starting at the one's that have no dependecies.
+ 
+<plain-beans.xml>
+ 
+This is a simple Micrcocontainer beans descriptior 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>
+
+As you can see, file's namespace is different from previous Microcontainer beans security-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>
+
+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.
+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.
+
+<guice-beans.xml>
+
+Two important parts to watch from this file are PojoModule and GuiceKernelRegistryEntryPlugin.
+The first one is where we configure our beans
+
+<PojoModule>
+
+where the second one is where the integration with Microcontainer lies
+
+<GuiceKernelRegistryEntryPlugin>
+
+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>
+
+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.
+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.
+
+<jmx-beans.xml>
+
+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>
+
+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>
+
+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>
+
+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.
+
+<alias-beans.xml>
+
+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.
+Meaning alias will wait in non-installed state until real bean triggers it.
\ No newline at end of file