> From: Peter Donald [mailto:[EMAIL PROTECTED] > > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
