cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Serviceable considered harmful (was Re: XSP not working in CVS head?)
Date Mon, 17 May 2004 14:39:46 GMT
Ugo Cei wrote:

> Sylvain Wallez wrote:
>> !!!!! A LogicSheet cannot be Serializable !!!!!
>> It extends AbstractLogEnabled and has attributes of type 
>> ServiceManager and SourceResolver, which aren't serializable !
> I'm really starting to appreciate the superior design of a container 
> like Spring with respect to Avalon. If the LogicSheet were a 
> Spring-managed bean, it would need no fscking ServiceManager:
>   <bean id="logicSheet" 
> class="org.apache.cocoon.components.language.markup.LogicSheet">
>    <property name="xsltProcessor">
>      <ref bean="xsltProcessor"/>
>    </property>
>   </bean>
> ...
>   public class LogicSheet {
>     private XSLTProcessor xsltProcessor;
>     public void setXsltProcessor(XSLTProcessor xsltProcessor) {
>       this.xsltProcessor = xsltProcessor;
>     }
>     ...
>   }
> 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.

I agree with this. Now IOC type 2/3 containers haven't solved the 
problem of non thread-safe components, and more generally relations 
between components of different lifestyles (e.g. ThreadSafe and 
Poolable). And Cocoon cannot live without this, unless some major 
refactoring leading to Cocoon 3

Also, how do IOC type 2/3 containers handle optional dependencies (e.g. 
TraxTransformer checking for the Deli component) ?

Finally, what frightens me with Spring configuration is the need to 
explicitely declare all dependencies. Imagine the size of a Spring-style 

> 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.

Is this really an aspect, when components cannot live without it 
(because they do produce specific error messages)? IMO, it's more a 
component dependency, but a crucial one as it must occur in the early 
stages of component setup. A good candidate for constructor injection.

> 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.

Just check that no subclasses exist that need it. Eclipse should tell 
you ;-)


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message