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...
HTH
Carsten
