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
