avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: SuperServicable
Date Mon, 03 Jun 2002 12:56:39 GMT
> From: Peter Donald [mailto:peter@apache.org] 
> 
> On Sun, 2 Jun 2002 18:27, Paul Hammant wrote:
> > Pete, folks,
> >
> > Introducting SuperServicable (for want of a better name).  
> Driven by 
> > the belief that service(..) could be a little more in 
> accordance with 
> > the IoC pattern.  Also inspired by recent xdoclet changes:
> >
> >    public void service(ServiceManager serviceManager) throws 
> > ServiceException {
> >        aThing = (AThing) serviceManager.lookup("thing-blah-role");
> >    }
> >
> > If we had ....
> >
> >   /**
> >     * @phoenix:dependency name="somepackage.SomeService" 
> type="direct"
> >     */
> >    public void setAThing(AThing aThing) {
> >        this.aThing = aThing;
> >    }
> >
> > .... then a reflection using adapter could invoke these 
> methods during 
> > lifecycle at the same point that Serviceable would have 
> been invoked.
> >
> > Thoughts?  Neat? Too much work for such a small thing ?
> 
> Interesting idea but I am not sure what it would gain you. 
> Sure its possible 
> but I guess the question becomes why use it. A simple "void 
> service(SM)" 
> method is less code and simpler IMHO. 


I agree.  There is a point of diminishing returns.  By passing
in the ServiceManager (the container lookup mechanism), we enable
the possibility to choose our lookup policy for each component.
We can do it on initialization (i.e. setAThing()...), or at runtime.
The reasons for doing either would depend on the system in question.
Cocoon makes use of pooled components, which in turn make it better
to aquire and release references at runtime.  Phoenix typically forces
the use of thread-safe components making it better to do it at
initialization time.

When we have a setAThing()..., you are adding complexity to the
Container that we would be better without.  You would also be
dynamically
increasing the initialization stage of the lifecycle.

One of the things that Avalon has going for it is a well defined
lifecycle.  I would hate to see it screwed up by dynamically adding
new component types.

Example:

org.apache.avalon.foo.Generator
com.microsoft.embrace.and.extend.Generator (incompatibly with the
origional)

How do we write the method signatures for these?

setOrgApacheAvalonFooGenerator()
setComMicrosoftEmbraceAndExtendGenerator()

(Can we say YUCK!)

Besides, it is too bean-like to do it that way.  -1.


--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message