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

[Christophe Laprun]

On Oct 8, 2009, at 7:44 PM, Julien Viet wrote:

>> 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 agree with you but the API does not change with the current  
> version of GateIn 3.x as it will be Pico reimplemented (wrapping)  
> the MC engine. It is what we agreed. So that is invalid to me.

That was for a long term benefit. Of course, if the goal is just to  
keep the pico API intrusion forever, then why bother with anything else?

>> 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...
>
> It's an API, MC also has an API under the form of annotations (and  
> more if you want such as the aware interface), it's certainly less  
> intrusive, nevertheless that remains a *proprietary* API. So that's  
> more valid but still, does not make a real point.

You don't have to use annotations if you don't want to.

> We all know that MC is a wonderful piece of engineering and its  
> development took 4 years, so we expect it better than pico, aren't  
> we ?
>
> What I was asking for is for instance as things such as
>
> 1/ "as MC is a real state machine, it performs a better dependency  
> resolution, where Pico does not have a real notion of start/stop  
> lifecycle"
>
> or
>
> 2/ "as MC is integrated with management, that would allow to provide  
> proper management of services within the EPP environment"
>
> those would be valid argument to me.

I'm sure that you know MC better than most of us and you already know  
reasons to switch to MC, so I'm not sure what point you're trying to  
make?

Pico is intrusive, doesn't allow flexible control of dependencies  
(whether at runtime or at wiring time), almost any DI framework would  
be better. Why MC instead of something else? Well, we already depend  
on it in the portlet container or in JBoss Unit (that you designed and  
implemented ^_^) and it fits our business as well as technical needs  
so we might as well use it instead of pico in the long term. Of  
course, if you have another DI framework in mind, you're welcome to  
let us know which one and why. :)

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