New MC article -- for all eager to implement new deployers ;-)

• http://java.dzone.com/articles/jboss-microcontainer-virtual-deployment-framework

We just released new JBossAS6 milestone - M2.

With this one we start off a new Microcontainer 2.2.x version series:

• VFS 2.2.0.Alpha2 -- minor bug fixes and a few hack removals
• Reflect 2.2.0.Alpha2 -- first one to include new Classpool project [1]
• MDR 2.2.0.Alpha1 -- down the optimization road, metadata annotations lookup
• Kernel 2.2.0.Alpha6 -- includes JMX [2], new Weld-int, asynchronous mode [3], ...
• CL 2.2.0.Alpha2 -- system resources are still visible at shutdown, lifecycle callbacks, shutdown mode, ...
• Deployers 2.2.0.Alpha1 -- deployers sorting fix, modification check based on known files, includes JMX, ...
• McAnn 1.0.0.Alpha1 -- extracted scanning; to-be even more generalized (McScan project)

Explaining the [x] in a bit more details:

1. Classpool is a project that will let us properly use Javassist based Reflect in JBossAS/MC
2. JMX impl used to be part of AS; extracted and split into 3 sub-projects: JMX-Kernel, JMX-Deployers, JBossMX
3. you can declare <bean name=Foo class=org.acme.Bar mode=Asynchronous> and its install will happen in a new thread

A lot of work in Kernel was done to support our new OSGi+MC facade and its transparent service/component mix.

• http://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/projects/runtime/framework/branches/alesj_service-mix/
• http://jaxlondon.com/conferences/trackssessions/?tid=1453#session-13375

Another big chunk of work in Kernel was also spent on optimizations, where Kabir did most of the heavy lifting, hence I'll let him talk about it. :-)

• http://kabir-khan.blogspot.com/2010/02/optimizing-jboss-microcontainer.html

We're off to changing VFS with new v3 implementation!

• http://lists.jboss.org/pipermail/jboss-development/2010-February/015781.html

It's been a while since the last blog entry and any MC DZone article. So, this entry is what will change this fact. :-)

I actually forgot to put a short blog about my previous DZone article, where I talk about our VFS

• JBoss Virtual File System

and here is the latest article, still hot from the print

• Microcontainer & ClassLoading

Enjoy!

ps: any feedback welcome, either directly on the articles or our MC users forum.

Last few weeks, apart from doing real work ;-), I've been hacking away a simple tool to display MC's components. I named the project Grapher, as that's what the project/app does - it creates a plain graph.

This is a plain graph of current JBoss5.1.0.GA's MC components. As we could already learn in DZone and MC component models, the component types (currently) span from POJOs, MBeans, Aliases, Deployments, Core services to any extension (KernelRegistryPlugin). And you can see there is a lot of them and it's not easy to put them all on the plain.

[AllGraphCreator] Vertices: 830, Edges: 1563

I'm using JGraph to do the rendering, while using its layout component only for personal usage (license requirement).

The project source code lives here, and any UI or core contribution is as always welcome. Specially UI part could do some work as I pretty much suck at it - currently all input/output is done via single servlet and broswer's address line. :-)

The code itself is nicely structured, split into functional pieces

• graph creation
• layout
• request mapping
• rendering
• routing
• analysis (TODO)

Graph creation has the following impl:

• All - show all components
• Bean - show component and its first level dependencies
• Tree - show component and all transitive dependencies
• Deployment - show deployment's components; recursion/transitivity is optional

Some examples

• http://localhost:8080/grapher/
• http://localhost:8080/grapher/?bean=MainDeployer
• http://localhost:8080/grapher/?tree=MainDeployer
• http://localhost:8080/grapher/?deployment=vfs-jboss-beans.xml
• http://localhost:8080/grapher/?deployment=vfs-jboss-beans.xml&recurse=true
• http://localhost:8080/grapher/?deployment=metadata-deployer-jboss-beans.xml&folder=deployers

Layout is hacked in via reflection due to license issues, but for personal usage you can use any of the following JGraphLayout impls

      // a ctor hack
      map.put("simple0", "com.jgraph.layout.graph.JGraphSimpleLayout");
      map.put("simple1", "com.jgraph.layout.graph.JGraphSimpleLayout");
      map.put("simple2", "com.jgraph.layout.graph.JGraphSimpleLayout");

      map.put("tree", "com.jgraph.layout.tree.JGraphTreeLayout");
      map.put("spring", "com.jgraph.layout.graph.JGraphSpringLayout");
      map.put("hierarchical", "com.jgraph.layout.hierarchical.JGrapHierarchicalhLayout");
      map.put("compound", "com.jgraph.layout.JGraphCompoundLayout");
      map.put("compact", "com.jgraph.layout.tree.JGraphCompactTreeLayout");
      map.put("moen", "com.jgraph.layout.tree.JGraphMoenLayout");
      map.put("radial", "com.jgraph.layout.graph.JGraphRadialTreeLayout");
      map.put("annealing", "com.jgraph.layout.graph.JGraphAnnealingLayout");
      map.put("fr", "com.jgraph.layout.graph.JGraphFRLayout");
      map.put("organic", "com.jgraph.layout.organic.JGraphOrganicLayout");
      map.put("self", "com.jgraph.layout.organic.JGraphSelfOrganizingOrganicLayout");
      map.put("isom", "com.jgraph.layout.graph.JGraphISOMLayout");
      map.put("org", "com.jgraph.layout.tree.OrganizationalChart");
      map.put("grid", "com.jgraph.layout.simpl.SimpleGridLayout");

where the default used is SimpleGridLayout.

• http://localhost:8080/grapher/?tree=MainDeployer&layout=isom

Note: I still need to check how to handle layout better, as I see too much of overlaps.

Each of the pieces can be changed at config or runtime.

public interface GraphComponentMapper<T>
{
   /**
    * Initialize.
    *
    * @param config the config map
    */
   void init(Map<String, String> config);

   /**
    * Map component from request.
    *
    * @param request the request
    * @return mapped component
    */
   T mapComponent(HttpServletRequest request);

   /**
    * Map component to the key.
    *
    * @param key the key
    * @param value the value
    * @return mapped component
    */
   T mapComponent(String key, String value);
}

Where I have such component mappers for graph creator, layout and renderer. The defaults are used at servlet initialization, but you can provide your own.

Currenly I support these renderers

• PNG (default)
• JPG
• GIF
• SVG
• Html ul/li

Renderer example

• http://localhost:8080/grapher/?tree=MainDeployer&renderer=svg

Any request can use any combination of these, plus some additional filtering.

You can list the component type excludes

      mapControllerContextClass("pojo", AbstractKernelControllerContext.class, Color.BLUE);
      mapControllerContextClass("alias", AliasControllerContext.class, Color.GRAY);
      mapControllerContextClass("core", BeanKernelRegistryEntry.class, Color.RED);
      mapControllerContextClass("ext", AbstractKernelRegistryEntry.class, Color.ORANGE);
      mapControllerContextClass("mbean", "org.jboss.system.microcontainer.ServiceControllerContext", Color.MAGENTA);
      mapControllerContextClass("dep", "org.jboss.deployers.plugins.deployers.DeploymentControllerContext", Color.GREEN);

Here you can also see the colors that are mapped against certain component type.

Exclude POJOs example

• http://localhost:8080/grapher/?exclude=pojo

Exclude multiple types

• http://localhost:8080/grapher/?exclude=mbean,ext,alias

Also availabe option is to define which dependecy type you wanna use to find dependencies

• IDepenOn (default)
• DependsOnMe
• Unresolved

• http://localhost:8080/grapher/?tree=MainDeployer&dependency=DependsOnMe

This leaves us with analysis piece, which is still WIP. The whole graph is backed by JBoss Common Core Graph code, hence we already have some of the theoretical algorithms present, but I would still like to do a bit more.

The current idea that I have is to somehow join rules/scripts with graph theory.

• give me all sub-graphs whose number of vertices is less than 20
• give me all sub-graphs with depth less than 5

This way we could do some proper analysis and easily determine how to place On-Demand mode and define lazy beans. But like I said, this is still very non-defined, so any help welcome. Wink wink our Drools committers. ;-)

Also good thing about the project is that most of if not all of the code is properly tested, with each functional piece having its matching test. So, when you contribute, you know when you broke something. ;-)

ps: Simple mvn package creates the grapher.war, for any useful layout check pom.xml ;-)

This year there will be huge presence of Microcontainer releated material at JavaOne.

To start off, I'll do a lightning talk at Drools boot camp on Monday June 1st.

Also on Moday, Scott Stark will present the new Virtual Deployment Framework, and I will share some tips and tricks on how to optimize MC's usage.

On Tuesday Scott will continue to share his MC experience with component model mixture patterns, and on Wednesday you can hear me talk about the new ClassLoading layer and our plans with OSGi.

With your head full of MC you'll probably be eager to share this knowledge at the famous JBoss party, not to mention the free drinks and a chance to grab core developers by the sleeve. ;-)

To wrap it all up, leaving the best for last, a whole hour of technical MC talk :-)

TS-8611 - Technical Session
JBoss AS5 Microcontainer Architecture
Ales Justin, JBoss, a division of Red Hat
Friday, June 05
12:10 PM - 1:10 PM
Esplanade 305

And the most important info, don't forget to ask for a MC T-shirt at our booth! :-)