quality@glassfish.java.net

Competitors - JBoss Microcontainer

From: Miroslav Nachev <miro_at_space-comm.com>
Date: Wed, 10 Dec 2008 09:54:18 +0200

The JBoss Microcontainer is a refactoring of JBoss's JMX Microkernel to
support direct POJO deployment and standalone use outside the JBoss
application server.
Features:
    * All the features of the JMX Microkernel
    * Direct POJO deployment (no need for Standard/XMBean or MBeanProxy)
    * Direct IOC style dependency injection
    * Improved lifecycle management
    * Additional control over dependencies
    * Transparent AOP integration
    * Virtual File System
    * Virtual Deployment Framework
    * OSGi classloading


http://www.jboss.org/community/docs/DOC-10668
The anonymous access URL is
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/
The Microcontainer source is split into several different projects
    * aop-mc-int - the aop integration
    * classloader - new classloader model, prepared to handle OSGi CL style
    * container - general metadata utilities, and virtual file system
usuable across projects
    * dependency - a generic dependency state machine
    * deployers - the virtual deployment framework (VDF) spi and
abstractions.
    * guice-int - guice integration
    * kernel - the microcontainer adding xml deployment and "javabeans" to
the above two projects
    * managed
    * metatype
    * osgi-int - osgi integration
    * reliance-identity - define identity as a MC POJO service
    * reliance-rules - define your dependencies with Drools
    * reliance-jbpm - define your dependencies with jBPM
    * spring-int - spring integration
The project can be built using maven 2. From the parent directory:
mvn install


JBoss MicroKernel - The JBoss Kernel provides a lightweight kernel for
managing POJOs, their deployment and configuration.
Additional features can be added:
    * Configuring a container for the POJO and and adding aspects.
    * Writing deployment aspects to add extra configuration steps for a
POJO/deployment.
 Aims:
    * Make the JBoss microkernel available as a supported standalone
project.
    * Re-implement the kernel inline with our POJO middleware strategy.
      - No requirement for JMX (which might not be available in some
environments).
      - No requirement to extend or reference JBoss classes.
      - Allow unit tests "outside" the JBoss server.
      - JMX still used by the JBoss server.
    * Allow JBoss services to be easily deployed in the other containers.
      - Removes any "lock in" associated with using JBoss Services.
      - The enclosing container may handle classloading, logging, etc.
    * Allow the features to be used in more restrictive environments (e.g.
Applets, J2ME, etc.)
      - Lightweight and small memory footprint.
      - May not be authorized to the MBeanServer, System properties, etc.
      - Layered approach - advanced features are optional, e.g. hot-deploy,
jmx or cluster support.
    * Improved configuration management.
      - Notion of manual/on-demand start of a service.
      - Versioned configuration profiles.
      - Permenant deployment/config changes when using management apis.
      - Notion of system/subsystem.
      - Notion of service/subservice as opposed to service/dependent
service.
      - Enhanced bootstrap.
    * Introduce an "Aspectized" deployer layer.
      - Deployment aspects for classloading, logging, configuration,
dependency injection, etc.
      - Virtual File System to improve and ease deployment/archive access
inside the deployers.
    * Use the container defined by the Unified Interceptor project.
      - Better integration with JBoss/AOP.
      - Allows reuse of interceptors/services from other parts of JBoss.
      - Provide kernel aspects - IOC, lifecycle, valve, state, etc.
    * Improved support for dependencies.
      - Classloading dependencies.
      - JNDI/port binding dependencies.
      - Better definition of implicit/explicit rules.
    * Improved support for clustering.
      - Clustered services - config and operations automatically propogated
according to metadata rules.
      - Transparent access to remote services in the cluster.