Marc Portier said the following on 23/5/07 12:26:
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...
Helma,
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 will see if that is true. For now I've applied the above patch to
DomHelper (rather than JXPathBindingManager) and I now at least get the
namespace reference from the source file.
However, the namespace attribute added to the binding file doesn't make
it into the DomHelper.
This is what I get:
source:
<oe:version xmlns:oe="openEHR/v1/Version">
....
</oe:version>
binding file:
<fb:context path="/oe:version" xmlns:oe="openEHR/v1/Version">
....
</fb:context>
They don't match on oe:version (missing context path)
Debugging after applying the above patch showed that the namespace URI
is present for the source file (before the patch is was null), but for
the binding I get something like "oe=<<unknown namespace>>"
Any ideas?
+ 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...
I just added a comment.
