Hi Miroslav,
Sorry, but this reads as an advertisement for JBoss for me. Would like
to know what is the point you want to make to the GlassFish users in
quality alias ?
Thanks,
Judy
Miroslav Nachev wrote:
> 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.
>