Bug when overriding the SourceResolver in a sub-sitemap

[Cédric Damioli <ce...@anyware-tech.com>]

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