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

[Julien Viet]

Hi Marko,

you mail is long to read but for now, I would like just to comment the  
two first points:

1/ I agree with you that it is not acceptable to not have source code

2/ I don't find this argument valid from my perspective, can you  
instead tell us what it would bring to use MC instead of pico

Julien

On Oct 8, 2009, at 1:39 PM, Marko Strukelj 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