cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [RT] Serviceable considered harmful (was Re: XSP not working in CVS head?)
Date Mon, 17 May 2004 14:53:04 GMT
Ugo Cei wrote:
> Sylvain Wallez wrote:
> Isn't this neater? No need to implement an Avalon interface. The problem 
> is, Serviceable breaks IoC big time. We preach the Hollywood principle 
> and then provide almost _ALL_ our components with a big telephone 
> directory. Component should be injected with all the needed 
> dependencies, not have to look them up through ServiceManager.

see below.

> And while we're at it, since "AbstractLogEnabled" was mentioned by 
> Sylvain, I'll vent my opinion on it too (feel free to spawn a different 
> thread if you want to reply to me on this subject). Well, my 
> (not-so-)humble opinion is that it sucks! It sucks because we are 
> reusing an aspect like "being log-enabled" via concrete *implementation* 
> inheritance. If this doesn't suck, in terms of good OO design, the tell 
> me what does. And we are doing this just to avoid the hassle of 
> declaring a "logger" member, a setter and a getter.

Ok, so LogEnabled is the interface, and AbstractLogEnabled is a way of
taking care of this aspect using inheritance, they are two different
methods of achieving the same thing.

> Oh, by the way, LogicSheet extends AbstractLogEnabled but does not 
> actually log anything. So I removed "extends AbstractLogEnabled" in my 
> local copy and will commit it after the release, if nobody objects.

I remember making a logging XSP logicsheet a while back, is this used/
still included?

OK, now to the topic of IoC, Serviceable, etc.  This is a fundamental
change to the framework that you may are suggesting.  Such a change is
not easy, and can be considered harmful unless you design your container
in a way to support heterogeneous component types.

You might want to take some inspiration from my Dojo project (note I
said inspiration--I am not suggesting you depend on my code unless you
feel it truly merits it).  The concept that I am designing and
evolving Dojo from is one where any one JAR file will have the same
kind of components in it--which is why I have one ComponentFactory per
Dojo.  This also greatly simplifies the design.  The default "budo" or
"framework" is similar to the Spring/JavaBean concept of using setters
and getters.  By default there is no configuration file.  There is no
automatic way to set up the dojo--until you add it as a layer on top.
I have a potential Avalon implementation on top of Dojo, but it is

Serviceable, and passing in a ServiceManager is technically IoC.
Granted, the default solution of allowing any component to look up
any other component it desires is not the safest--but it is the
easiest--solution for the problem of getting other components in an
Avalon context.  Both Merlin and Phoenix demonstrate that you can
have an Avalon system that only provides the declared dependencies.
There is an inherent complexity in this system, and adds to the code
bloat.  On the other hand, a solution based only on reflection does
place an incredible burden on trying to improve performance.  Even
using a dynamically created proxy class without reflection is expensive.

To be sure there is no perfect solution, but the "Spring" style
component using setters and getters is natural to a great number of
developers.  The "pico" style component using constructor parameters
is also very natural to a great number of developers.  Sometimes a
hybrid can be used like constructor parameters for required components
and setters and getters for optional components.  The setter/getter
approach does make the testing of the component much easier.  However
do recognize that Cocoon has a certain inertia that must be redirected.
I suggest small corrective improvements to get Cocoon where you would
like to be.

View raw message