You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/06/02 10:27:40 UTC

SuperServicable

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 ?

- Paul


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: SuperServicable

Posted by Paul Hammant <Pa...@yahoo.com>.
Berin, Peter,

Yeah yeah, I'm convinced.

->  "Just because we can does not mean that we should"

-ph




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: SuperServicable

Posted by Berin Loritsch <bl...@apache.org>.
> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: SuperServicable

Posted by Peter Donald <pe...@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. 

-- 
Cheers,

Peter Donald
 "Man's mind stretched to a new idea never goes back to its original 
dimensions." -Oliver Wendell Holmes 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>