Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 60519 invoked from network); 4 Jan 2007 11:15:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Jan 2007 11:15:31 -0000 Received: (qmail 34045 invoked by uid 500); 4 Jan 2007 11:15:36 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 33984 invoked by uid 500); 4 Jan 2007 11:15:36 -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 List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 33963 invoked by uid 99); 4 Jan 2007 11:15:35 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO [127.0.0.1]) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Jan 2007 03:15:35 -0800 Message-ID: <459CE235.3040306@apache.org> Date: Thu, 04 Jan 2007 12:17:09 +0100 From: Carsten Ziegeler User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Problems with writing sitemap components as spring beans References: <459376E7.5020002@apache.org> <45937D8D.6010506@apache.org> <45938218.4020100@apache.org> <459404D1.7000600@gmx.de> <4594E2D7.9070508@apache.org> <4597AECA.8000901@nada.kth.se> <45994748.1070300@apache.org> <459CDDDB.4040600@nada.kth.se> In-Reply-To: <459CDDDB.4040600@nada.kth.se> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Daniel Fagerstrom wrote: > After having looked at I think that the simplest solution would be to > just provide one (singleton) info bean for each component. Something like: > > > > > > > class="org.apache.cocoon.serialization.XMLSerializer" > scope="prototype" > parent="org.apache.cocoon.serialization.AbstractTextSerializer"/> > > Then the ProcessorComponentInfo can just look up the info from the > container using .ROLE//info as key. > > If it is better to store the info in the ProcessorComponentInfo, we > could have a bean factory that looks up the ProcessorComponentInfo (or > create it if needed), and store the info there instead: > > > class="org.apache.cocoon.core.apropriate_sub_package.ProcessorComponentInfoBeanFactory"> > > > > > In this case the bean name is parsed for finding out what sitemap the > component info is about. We could combine any of the above solutions > with a custom xml format if we like to get a "prettier"notation. > I think the first solution is the a little bit easier to implement and does not require to much coding in xml for the configuration, so I think we should go for the first solution. If anyone has time to imlement it, we could think about adding our own tags for this configuration, so this could look like this:

This shouldn't be too hard. > Whatever solution we use, the mechanism for being able to store the info > must be part of the pipeline layer, so that we can configure the > pipeline components there. Yes, it would be good if we could move this stuff out of the current avalon bridge! Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/