>>>>> "DL" == Daniel Lopez <[EMAIL PROTECTED]> writes:
DL> I had never seen "jndi:" as protocol descriptor before, but in the
DL> end I think it was still an XML parser compatibility issue.
I can't understand how a parser issue would lead to an inability to
to open a file that clearly exists, but I'm happy to hear you got past
it.
DL> I was able to solve it by changing my implementation to work with
DL> crimson and not using xerces anymore. [...] until I completely
DL> removed xerces from the classpath, not even putting crimson.jar
DL> before it in the classpath worked, it kept on giving me strange
DL> errors like "class not found", "no such method" from classes that
DL> were in the classpath and methods that existed, and some "null
DL> pointer" also. This xml parser issue is a big headache. I think I
DL> read it was planned to make batik xml-parser-independent, is that
DL> true?
Yes, and in fact I believe we are XML _parser_ independent. We
still require an XML _DOM_ level 2 implementation, which I believe is
where most people get into trouble with the "class not found", and "no
such method" errors (Thierry can answer this more authoritatively).
Fixing this problem requires ensuring that the _Batik_ jars (not just
crimson) are before xerces in the classpath.
DL> My opinion is that it will save batik people lots of trouble, as
DL> they would get less messages regarding strange errors.
If I am correct and the problem is not the XML parser but the DOM
implementation there is nothing we can do, since the SVG DOM requires
DOM level 2, so we simply can not use DOM level 1 as the basis of our
implementation...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]