Re: [picocontainer-dev] javax.inject.*

2009/5/5 Paul Hammant <[email protected]>:
> http://google-code-updates.blogspot.com/2009/05/javaxinjectinject.html
>
> Last summer Bob, Rod and I met for a lunch to discuss potential for
> commonality, for the DI frameworks that we represent.  We came away with
> more questions than answers.  Since then things move on of course, and we*
> see that Seam is trying to introduce a DI specification, and the Guice has
> made popular the form of DI that PicoContainer started many years ago, its
> Provider<T> style proves popular too.  Annotated DI has been introduced by
> EJB 3.0 (and got wrong) and Guice made it better.  All of Spring, Pico and
> Guice are now using annotations, and maybe its smart to settle on a single
> spec for that, to allow component interop.  Also on the table with this JSR
> (and immensely important to me in particular) is the principle of Lowest
> Common Denominator.  For example, Spring folks may suggest that XML
> meta-data is still the correct way to do DI, but the spec leaves that open
> to the container makers and does not force it on the component coders.
>
> So we're still going to support components with no annotations, as we always
> did, but it seems smart to settle on this spec's annotations for situations
> where the component coder prefers it.

Good to see progress on standardising annotations for DI, even if
JSR-299 doesn't want to play.

What concerns me is the trend of annotating components with IoC
configuration.  Surely this is not particularly IoC?  Why enforce
clients to use a specific constructor with @Inject when convention
(most satisfiable) or container configuration could be used?  Why
annotate setters with @Inject when it's pretty obvious that they can
be set?  Why resolve ambiguous dependencies *within* the component
using qualifier annotations when it's surely the client's
responsibility to decide?

On one hand we're inverting control of dependencies to the component's
client, and then on the other we're hardcoding component configuration
within itself.  I appreciate that Pico will continue to support
components without annotations, but I was wondering if this topic had
come up when chatting with the Guice/Spring guys?  It'd be good to see
a standard API emerge for configuring a container, although I guess
this is still volatile ground at the moment.

Mark

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email