cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: CForms binding with namespaces error - advice wanted
Date Wed, 23 May 2007 10:26:53 GMT

Carsten Ziegeler wrote:
> hepabolu wrote:
>> Joerg Heinicke said the following on 22/5/07 22:18:
>>> On 22.05.2007 17:07, Helma van der Linden wrote:
>>>> // Create the SAX parser and set the features so it creates the 
>>>> events we need
>>>>                SAXParser parser = 
>>>> (SAXParser)manager.lookup(SAXParser.ROLE);
>>>>                if( parser instanceof Parameterizable ) {
>>>>                    Parameters params = new Parameters();
>>>>                    params.setParameter("namespace-prefixes","true");
>>>>                    ((Parameterizable)parser).parameterize(params);
>>>>                }
>>>> but I'm wondering if that is the correct place to do that.
>>>> OTOH, if it's done at a more global scale, would that have unwanted 
>>>> side-effects?
>>> I don't know how SAXParsers are set up. But if they are pooled, even 
>>> this change has side effects since the SAXParser is returned to the 
>>> pool parameterized. Anyway this code smells. No idea how to do it 
>>> otherwise though.
>> Do you have any idea about what will happen if the parameter setting 
>> is added at creation time of the SAXparser? I.e. will it affect 
>> performance, memory consumption, behaviour of other parts of Cocoon?
> The above code really smells :) It is even not guaranteed to work as 
> passing a new set of paramters might not change all of the interal state 
> of the component. This might be done in initialize() etc.
> In addition if the parser would be thread safe it would change all uses 
> of the parser. As noted above, even if the parser is pooled it's causing 
> site effects.
> So, the only solution is to lookup the parser with the correct 
> configuration which means adding another configuration to cocoon.xconf 
> and giving it a different role. Then you look up exactly this instance 
> and use it.
> There is a minimal memory overhead with this solution but that can be 
> neglected.
> I never liked the sax parser interface (and dom) because of this. It 
> would be better if I could pass information like if the parser should 
> validate etc. at runtime, e.g. by parse(InputSource, ParserParameters).
> We could do this with the new parser interfaces in 2.2...


you might also want to check up on the second comment in that bug report
haven't got time to delve into it, but it sounded as a more in depth 
understanding of the root cause and an appropriate solution

+ I would comment  (or even close-wontfix?) that bug with a reference to 
the above conclusion from carsten.  Just in case somebody would want to 
apply the patch without giving it more thought...


View raw message