avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Plans for Constructor/Setter Injection?
Date Fri, 12 Mar 2004 10:36:11 GMT
Stephen McConnell wrote:
> > I wasn't very precise in my email, but what I meant if it's 
> possible 
> > to get a service via Constructor (or a setter), like
> > 
> > public ServiceImpl2(AnotherService o)
> > 
> > or
> > 
> > public void setAnotherService(AnotherService o).
> No - this is not supported.
> Using ServiceManager (or Context, etc.) maintains consistency 
> and familiarity with A4 usage patterns which I felt to be a 
> really high priority.
> While adding support for service injection is certainly 
> possible from a technical point-of-view - there are a lot of 
> issues that this raises. 
> In particular it opens up potential inconsistencies between 
> meta-info dependency declarations and dependencies implied by 
> a constructor signature. With standalone meta-info its is 
> possible to do a lot of work independently of the existence 
> or loading of a component class (without any ambiguity).  
> This information provides us with the optional status of a 
> service dependency, the service version, etc.  In contrast a 
> constructor signature is a poor cousin.  One has to also 
> consider the management of context entries in the same scope 
> (also declaring optional status and semantics related to lifestyle).
> My Current thinking is that injection of services (and/or context
> entries) introduces inconsistencies that outway the benefits. 
>  But this is the purpose of getting something out there so we 
> can play and get a feel for the right balance.
Yes, this might be true - now, I'm asking this because several
other containers offer this feature. Regardless of the inconsistencies
it allows you to use implementations within the container without
modifying your implementation at all.

To be honest, I really don't know if it's worth having this feature.
Apart from the problems you mention above, I see possible problems
in multi-threaded environments, when pooled and thread safe
implementations are mixed and you don't have any control about it
any more.
But on the other hand, it's a very nice - and simple feature for
component developers.


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message