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 cocoon.xconf...
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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
