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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

On Oct 8, 2009, at 2:31 PM, Julien Viet wrote: > 1/ I agree with you that it is not acceptable to not have source code +1 > 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 Less invasive DI framework. Better support for wiring of POJOs. For example, with the current implementation, I had to add a useless (from the code perspective) argument to my service constructor just to make sure that the service would be instantiated after some other one: real bad design!

I do agree that eating our own dog food is not a goal in itself but any DI framework that forces you to implement non-business interfaces and doesn't allow to explicit dependencies outside of your code cannot really call itself a real DI framework...

Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow JBoss Portal: http://jbossportal.blogspot.com / http://twitter.com/jbossportal Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm