Return-Path: 
 <dev-return-94219-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 11048 invoked from network); 14 Apr 2007 00:10:51 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 14 Apr 2007 00:10:50 -0000
Received: (qmail 2642 invoked by uid 500); 14 Apr 2007 00:10:55 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 2558 invoked by uid 500); 14 Apr 2007 00:10:55 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 2537 invoked by uid 99); 14 Apr 2007 00:10:55 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Apr 2007 17:10:55 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Received: from [212.27.42.29] (HELO smtp3-g19.free.fr) (212.27.42.29)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Apr 2007 17:10:48 -0700
Received: from [127.0.0.1] (bon31-5-82-241-233-86.fbx.proxad.net
 [82.241.233.86])
	by smtp3-g19.free.fr (Postfix) with ESMTP id 0549A5C831
	for <dev@cocoon.apache.org>; Sat, 14 Apr 2007 02:10:24 +0200 (CEST)
Message-ID: <46201BE6.4080205@anyware-tech.com>
Date: Sat, 14 Apr 2007 02:10:14 +0200
From: =?ISO-8859-1?Q?C=E9dric_Damioli?= <cedric.damioli@anyware-tech.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Bug when overriding the SourceResolver in a sub-sitemap
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 000733-1, 13/04/2007), Outbound message
X-Antivirus-Status: Clean
X-Virus-Checked: Checked by ClamAV on apache.org

Hi all,

I just discovered a strange behaviour with Cocoon 2.1.10.
I have created a dummy, easily, reproducible sample to demonstrate it :

Let suppose you want to add a new SourceFactory implementation in a 
sub-sitemap, you may write something as :

<map:components>
    <source-factories>
        <component-instance 
class="org.apache.cocoon.components.source.impl.ContextSourceFactory" 
name="context2"/>
    </source-factories>
</map:components>

Actually, you also have to declare again the SourceResolver component at 
this level, so that it will be declared in the correct ComponentManager.

<map:components>
    <source-resolver 
class="org.apache.excalibur.source.impl.SourceResolverImpl"/>
    <source-factories>
        <component-instance 
class="org.apache.cocoon.components.source.impl.ContextSourceFactory" 
name="context2"/>
    </source-factories>
</map:components>


and then use it in your pipeline with :

<map:match pattern="foo">
    <map:generate type="file" src="context2://welcome.xml"/>
    <map:serialize type="xml"/>
</map:match>


However, it does not work...
And why ? Because in the FileGenerator, as in all others sitemap 
components, the SourceResolver object given in the setup() or act() 
method is the wrong one (ie that of top CocoonComponentManager).
So the resolver.resolveURI("context2://welcome.xml") will fail.

Of course, if I execute 
manager.lookup(SourceResolver.ROLE).resolveURI("context2://welcome.xml"), 
it is totally correct, because it uses the good SourceResolver (that of 
the sitemap's CocoonComponentManager).

So anybody has an idea ? Why maintaining two parallel SourceResolver 
objects in all Cocoon internals (that of the TreeProcessor (correct one) 
and that of the Environment (wrong one)) ?

This example is of course very simple, but my real life production app 
has a similar need.

Any help appreciated.

Regards,
C�dric