[gatein-dev] A word about Exo kernel - MC integration

[Dimitri BAELI]

Thanks,
  Can you simple precise what MC stands for and some documentation link to
it, or useful informations about this project.
  I'm guessing that's JBoss Micro Container : http://jboss.org/jbossmc
  Not everybody is used to know the JBoss libraries, yet :-)
Dimitri BAELI - eXo Platform SAS


On Thu, Oct 8, 2009 at 1:39 PM, Marko Strukelj <marko.strukelj at gmail.com>wrote:

>
> In order to facilitate finalization of MC instegration attempt I'm
> outlining here current work, so that Exo guys working on eXo kernel see what
> I'm doing, and also to maybe get some additional ideas about the
> functionality.
>
>
> Initial Objectives:
>
> o1) Get rid of picocontainer-1.1 (because there is no source code for it,
> and that's unacceptable for EPP 5)
> o2) Make some kind of integration with MC in order to - 'eat our own dog
> food'
>
>
> Constraints:
>
> c1) Picocontainer was thought to be heavily used directly (not only though
> exo kernel), which led to the belief that we have to keep at least
> picocontainer-1.1 compatible API in there
>
>
> Development:
>
> Initial investigation showed that apart from exo kernel (which in principle
> we can move to any other DI framework), other exo code, publicly available
> through svn, only makes use of 2 interfaces:
>
>  - org.picocontainer.ComponentAdapter
>  - org.picocontainer.Startable
>
>
> There is however a possibility that some of current Exo clients use
> picocontainer directly in ways we don't know about.
>
> I started my initial work on picocontainer-1.2 for which there are publicly
> available sources. Comparison with picocontainer-1.1 showed that there was
> some slight refactoring, some functionality was added, and some method
> signatures changed in declared exceptions only.
>
> Dropping picocontainer-1.2 in jboss-gatein distribution instead of
> picocontainer-1.1 results in everything running fine.
>
> That means that we can fulfill our objective o1) simply by upgrading to
> picocontainer-1.2. Exo should test this more extensively with some of their
> deployments.
>
>
> The initial idea to fulfill o1) and o2) at the same time was to rewrite
> picocontainer internals to delegate everything to MC.
>
> The problem that immediately showed was that API of the both libraries was
> quite different, and difficult to map.
>
> Another problem was that it turned out object instantiation wasn't left to
> picocontainer's code, but was overriden and was done in ExoContainer .
> createComponent() method, which also takes care of which constructor to call
> and fetches all the necessary argument values. DI is in effect implemented
> inside ExoContainer and not really delegated to picocontainer.
>
> So the first idea was just to delegate to MC kernel the holding of
> configuration objects or instances.
>
> But MC kernel actually has a nice pluggability mechanism where you can
> expose to it other object stores and it will delegate component lookup to
> them.
>
>
> The most recent implementation doesn't touch picocontainer at all.
>
> The idea is to do 2 things - a) use MC in a way that adds some substantial
> new functionality - specifically AOP support, b) expose gatein components to
> MC so they can be injected into other components deployed directly through
> MC (should such components exist).
>
> Currently all the containers used for DI by exo kernel extend
> org.exoplatform.container.ExoContainer, which itself extends another
> container:
>
> DefaultPicoContainer
> |- CachingContainer
>    |- ManageableContainer
>       |- ExoContainer
>          |- RootContainer
>
>
> I introduced MCIntegrationContainer:
>
> DefaultPicoContainer
> |- MCIntegrationContainer          <----
>    |- CachingContainer
>       |- ManageableContainer
>          |- ExoContainer
>             |- RootContainer
>
>
> This one can intercept all the calls to DefaultPicoContainer and do the
> necessary calls to MC kernel.
>
> Additional interception is performed through MCComponentAdapter that we
> wrap around any component adapter passed to
> registerComponent(ComponentAdapter) method.
>
> The interception passes the objects instanciated by ExoContainer's
> createComponent() - the actual point in the code where all instantiations
> occur -  through MC kernel that wraps them in AOP proxies.
>
> Since MC integration is now in the service of providing AOP, I also added
> an annotation called InterceptMC, that you put on your service class (the
> one that typically implements org.picocontainer.Startable), and we MC
> intercept only objects of classes that carry this annotation. All the other
> objects pass through the calls as if none of this new functionality is
> there.
>
> To use the functionality, you make a jar or war file with your service
> component annotated with InterceptMC, you put conf/configuration.xml in it,
> as usually. But then you can also add MC configuration next to it as
> conf/mc-beans.xml. It's the same configuration used in jboss-as. You can
> install new POJO components directly through it, and you can set up AOP
> there. You can pack in you jar a custom interceptor, and precisely configure
> the types and methods that should be intercepted with your custom
> interceptor.
>
> You can add extra logging, performance measurements and things like that by
> simply adding an interceptor class, tweaking config and repacking
> /redeploying the jar.
>
> Everything doesn't yet work as described, but I outlined the idea.
>
>
> I'll be glad to answer any questions ...
>
> Cheers,
>
> - marko
>
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/gatein-dev/attachments/20091008/79160461/attachment-0001.html