cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: CallFunctionNode problems in trunk
Date Fri, 12 May 2006 14:15:30 GMT
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> Giacomo Pati schrieb:
>>> I'm hunting that bug too ;-)
>>> My observation until now is that:
>>> a) SitemapLanguage#createNodeBuilder creates the CallNodeBuilder
>>> b) it seems (during my debugging) there is only one CallNodeBuilder in
>>>    the system (even though it is not marked ThreadSafe as other
>>>    NodeBuilders)
>>> c) in CallNodeBuilder#buildNode the member variable node will be
>>>    overwritten each time that method is called (and it is called for
>>>    each <map:call .../> element)
>> The SitemapLanguage uses the StandaloneServiceSelector which only deals
>> with singletons,
>> so currently a node builder must be a singleton. So, the question is if
>> we either try to fix this in a node and use the contract that each
>> builder is a singleton or fix the standalone service selector.
>> I think we should go for option one and require all builders to be
>> singletons.
> hmm, what has changed so that it stopped to work?
I don't know - history is not available :) But this might have to do
with the new spring based container. The old version did use ECM++ for
both, setting up the "real" container and the one for the treeprocessor
(at least I think it was this way). The new version does not use Spring
for the tree processor node builders but the standalone service selector
(which is the right way to go as this frees the tree processor from the
used container).

Carsten Ziegeler - Open Source Group, S&N AG

View raw message