1 Reply Latest reply on Dec 19, 2006 7:26 AM by Adrian Brock

    What happened to Microcontainer 2.0.0.M1 - a progress report

    Adrian Brock Master

      Since the release of 1.0.2 has been a while I wanted to
      explain why the 2.0.0 release hasn't happened (yet) and
      a bit about what it contains.

      2.0.0 adds AOP to the Microcontainer

      2.0.0 is finished (has been since about March), the remaining tasks are

      1) AOP 2.0 to use the org.jboss.metadata metadata repository rather
      than the original org.jboss.repository implementation

      2) Complete the org.jboss.metadata implementation.
      It is basically done, but the integration hooks like AOP are not there.

      3) Some tidyup of parts of the api to remove redundant stuff
      that was adding during 2.0.0 development and then replaced
      as well as extending some api like ControllerContextAware
      to the entire lifecycle not just registration.

      4) Productization work - I need to sit down and write some examples
      about some of the new features.

      (4) is the main reason why there hasn't been a release.
      There would be little point producing a release without
      explaining some of these new features (a few simple tasters
      are at the end of this).

      The other reason is that a lot of this work is being done for JBoss5
      what we also call the "Microcontainer project" but it actually
      has little to do with the basic IOC container beyond using it.

      In fact, if you download the current JBoss5 code from trunk,
      it uses the Microcontainer instead the JMX MicroKernel
      (well actually the JMX MicroKernel still exists as a facade over the Microcontainer).

      So basically, the JBoss Microcontainer 2.0.0 schedule has been
      incorporated with the JBoss5 schedule.
      Betas and release candidates will be alongside the AS releases.

      As promised Simple tasters:

      1) AOP integration - instance level AOP
      You can "annotate" an MC bean such that only for that POJO
      instance something special happens. e.g.
      make a particular instance a webservice (even though
      the original class didn't have the anotations).

      <bean name="Whatever" ...>

      2) AOP integration - "aspectized" dependencies

      Suppose you wanted to apply transaction demarcation
      (REQUIRED, NOT_SUPPORTED, etc.) to some pojos.

      This requires an interceptor but the interceptor also
      requires a dependency (the transaction manager).

      This dependency is an implementation detail that shouldn't
      have to be made on every bean.

      Instead, the AOP/MC integration automatically works out
      the dependency for you. You can simply annotate the bean
      which will
      1) Introduce the interceptor
      2) Add the dependency that the interceptor must be started
      which transitively needs some other service (the TM in this case).

      e.g. (this is pseudo, i.e. the names are not real)

       Deploy the aspect so it is known to the microcontainer
       The pointcut just says apply this aspect to any pojo
       with the annotation
       <aop:aspect xmlns:aop="urn:jboss:aop-beans:1.0"
       pointcut="execution(* @org.jboss.tm.TxDemarcation->*(..))">
       <property name="transactionManager"><inject bean="TransactionManager"/></property>
       <!-- The transaction manager -->
       <bean name="TransationManager class="org.jboss.tm.TxManager"/>

      Now it will apply this interceptor to the following class
      public class MyPOJO {}

      Or if the class didn't have the annotation, you can add it
      at deployment
      <bean name="test" class="com.acme.MyPOJO">

      Of course a real implementation would probably use the EJB3 annotations
      and the jboss-aspects project's interceptors.

      NOTE: The bean is guaranteed to start only after the interceptor
      is ready and that only when the transaction manager is ready.