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

>
> 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?

Agree.

> 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?

Bob Lee, Kevin Bruillion, Jesse Wilson (Guice folks) and Rod Johnson  
(Mr Spring) will all report that I've positively advocated Pico's more  
advanced features to them on and off over the years, encouraging them  
to implement the same (mostly transparent) features.

> 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.

It is.  This JSR good. There was going to be a possibility that  
everyone would have to support everyone else's @Inject annotation, but  
that's gone now.  The JSR 299 initiative has no authority, it not  
being from the DI community.  Previous Gavin King had touted "Bi- 
jection" as much-better than Dependency Injection.  In fact there was  
a time in 05/06 when he came to a ThoughtWorks away day in Chicago and  
presented on Seam and it's (then) leverage of Bi-jection.

Regards,

- Paul

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

    http://xircles.codehaus.org/manage_email