Hi Thomas,
Thomas E Deweese wrote:
>
> >>>>> "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.
I have to admit I don't get it either ;), but changing the classpath and
removing completely the xerces.jar file solved it, so that's why I guess
it was an XML parser compatibility issue. My guess would be that the
parser had specified an EntityResolver that was not able to find the
file, even though it exists. The "jndi:" part is the one I don't get,
but I'm not an expert in XML parsers so...
>
> 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.
Why is it so? I mean, I'm using Xalan 2 which includes a Xerces version
which
supposedly is a XML DOM level 2 implementation, and I could not get it
to work with xerces in classpath, I had to remove the file. Part of the
problem is that current servlet engines handle classpath issues quite
strangely, as the JSDK2.2 specification was not clear enough. Actually,
I think that it now works because latest version of Orion already
includes crimson.jar.
>
> 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...
I agree with you, but if Xerces claims to be a DOM level 2
implementation, shouldn't batik work with the latest Xerces version?
Here is the link to xerces, claiming that:
http://xml.apache.org/xerces-j/
Now that I know that it works, I might still play a bit to see if I can
make it to work with a different version of Orion, with xerces after
crimson in the classpath... If I come across something interesting, I'll
let you know.
Thank you for your help,
D.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
