Re: [gatein-dev] A word about Exo kernel - MC integration
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