Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 69056 invoked from network); 17 May 2004 14:39:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 17 May 2004 14:39:58 -0000 Received: (qmail 58871 invoked by uid 500); 17 May 2004 14:40:03 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 58775 invoked by uid 500); 17 May 2004 14:40:02 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 58755 invoked by uid 98); 17 May 2004 14:40:02 -0000 Received: from sylvain@apache.org by hermes.apache.org by uid 82 with qmail-scanner-1.20 (clamuko: 0.70. Clear:RC:0(217.112.237.100):. Processed in 0.377577 secs); 17 May 2004 14:40:02 -0000 X-Qmail-Scanner-Mail-From: sylvain@apache.org via hermes.apache.org X-Qmail-Scanner: 1.20 (Clear:RC:0(217.112.237.100):. Processed in 0.377577 secs) Received: from unknown (HELO mail.anyware-tech.com) (217.112.237.100) by hermes.apache.org with SMTP; 17 May 2004 14:40:02 -0000 Received: from apache.org (firewall.anyware [10.1.0.254]) by mail.anyware-tech.com (Postfix) with ESMTP id B068C5EB88 for ; Mon, 17 May 2004 16:39:47 +0200 (CEST) Message-ID: <40A8CEB2.10800@apache.org> Date: Mon, 17 May 2004 16:39:46 +0200 From: Sylvain Wallez Organization: Anyware Technologies User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: fr, en, en-us MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [RT] Serviceable considered harmful (was Re: XSP not working in CVS head?) References: <36700.10.0.0.5.1084790016.squirrel@ags01.agsoftware.dnsalias.com>

<40A8C005.5040508@apache.org> <40A8CB63.1060604@cbim.it> In-Reply-To: <40A8CB63.1060604@cbim.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: hermes.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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: > > > class="org.apache.cocoon.components.language.markup.LogicSheet"> > > > > > > ... > > 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 }