You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Daniel López <D....@uib.es> on 2001/08/20 08:00:04 UTC
[Fwd: [Fwd: svg-20001102.dtd not found.]]
Hi,
Nobody in the users list could help me, as it might require an inside
knowledge of batik, so here I go:
I'm trying to process an SVG file inside a servlet to show a JPEG image
and after dealing with a couple of XML parser incompatibility issues,
I've stumbled into this error. When I process the SVG file, a sample
file provided with the batik-1.1rc, I get the error:
java.io.IOException: File
"jndi://D_/Apps/Test/Test/Test/WEB-INF/lib/batik-svg-dom.jar/org/apache/batik/dom/svg/resources/svg-20001102.dtd"
not found.
The file batik-svg-dom.jar is in the classpath and it is exactly in
D:/Apps/Test/Test/Test/WEB-INF/lib/, I also checked to see that the dtd
file is in there and indeed, it is. Any clues?
This is how I'm processing the file, extracted from the sample files and
some messages from this list archive:
//****
// create a JPEG transcoder
JPEGTranscoder t = new JPEGTranscoder();
// set the transcoding hints
t.addTranscodingHint(JPEGTranscoder.KEY_XML_PARSER_CLASSNAME,
"org.apache.crimson.parser.XMLReaderImpl");
t.addTranscodingHint(JPEGTranscoder.KEY_QUALITY,
new Float(.8));
// create the transcoder input
SAXSVGDocumentFactory svgFactory = new
SAXSVGDocumentFactory("org.apache.xerces.parsers.SAXParser");
String svgNS = SVGDOMImplementation.SVG_NAMESPACE_URI;
// Input is the sample file batik3D.svg, read as an InputStream
Document document =
svgFactory.createDocument(svgNS,xmlSource.getInputStream());
TranscoderInput input = new TranscoderInput(document);
// create the transcoder output
response.setContentType("image/jpeg");
TranscoderOutput output = new
TranscoderOutput(response.getOutputStream());
// generate/show the image
t.transcode(input, output);
//****
Any clues what might be going wrong?
Thanks in advance,
D.
PD: I also tried with batik1.0 with no luck. Platform is WinNT,
Orion1.4.5, JDK1.3
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: [Fwd: [Fwd: svg-20001102.dtd not found.]]
Posted by Stephane Hillion <sh...@ilog.fr>.
On Tuesday 21 August 2001 14:01, Daniel López wrote:
>
> > 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?
There are a lot of things which make it impossible, but the most important is
that xerces, crimson and all other DOM2 implementations do not implement the
DOM2 Style module.
--
Stephane.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: [Fwd: [Fwd: svg-20001102.dtd not found.]]
Posted by Daniel López <D....@uib.es>.
Hi Thomas,
Thomas E Deweese wrote:
>
> >>>>> "DL" == Daniel Lopez <D....@uib.es> 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: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: [Fwd: [Fwd: svg-20001102.dtd not found.]]
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "DL" == Daniel Lopez <D....@uib.es> 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: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: [Fwd: [Fwd: svg-20001102.dtd not found.]]
Posted by Daniel Lopez <D....@uib.es>.
Hi Thomas,
I had never seen "jndi:" as protocol descriptor before, but in the end I think it was still an XML parser compatibility
issue. I was able to solve it by changing my implementation to work with crimson and not using xerces anymore. It's a
good thing I was JAXP compatible so I just had to remove some lines that used the "node.normalize()" method. Anyway,
until I completely removed xerces from the classpath, not even putting crimson.jar before it in the classpath worked, it
kept on giving me strange errors like "class not found", "no such method" from classes that were in the classpath and
methods that existed, and some "null pointer" also. This xml parser issue is a big headache.
I think I read it was planned to make batik xml-parser-independent, is that true? My opinion is that it will save batik
people lots of trouble, as they would get less messages regarding strange errors.
On the other hand, Orion is the servlet container (application server if you wish) that we use, as it is one of the
fastest and it is free for educational institutions. If you don't mind the terrible support, and the lack of
documentation, it is pretty good. It is actually the core of the new Oracle9IAS. As many servlet containers nowadays, it
includes its own XML parser to read the configuration files, hence the conflict with crimson. I actually had to upgrade
to a latest version, which also uses crimson, to get it to work. I think you'll get lots of messages from people trying
to use batik inside servlets and getting weird problems with XML parsers, as it is a common source of headaches. I wish
JDK2.3 solves it.
Thank you very much for your help,
D
Thomas E Deweese wrote:
> >>>>> "DL" == Daniel =?iso-8859-1?Q?L=F3pez?= <Daniel> writes:
>
> DL> Nobody in the users list could help me, as it might require an
> DL> inside knowledge of batik, so here I go: I'm trying to process an
> DL> SVG file inside a servlet to show a JPEG image and after dealing
> DL> with a couple of XML parser incompatibility issues, I've stumbled
> DL> into this error. When I process the SVG file, a sample file
> DL> provided with the batik-1.1rc, I get the error:
>
> DL> java.io.IOException: File
> DL> "jndi://D_/Apps/Test/Test/Test/WEB-INF/lib/batik-svg-dom.jar/org/apache/batik/dom/svg/resources/svg-20001102.dtd"
> DL> not found. The file batik-svg-dom.jar is in the classpath and it
> DL> is exactly in D:/Apps/Test/Test/Test/WEB-INF/lib/, I also checked
> DL> to see that the dtd file is in there and indeed, it is.
>
> DL> Any clues?
>
> Well, basically no...
>
> It appears that everything is fine on the Batik side of things.
> I've never noticed a 'jndi' protocol descriptor on a URL though. As I
> recall the Sun JDK uses 'jar' for a URL like the one above...
>
> DL> Platform is WinNT, Orion1.4.5, JDK1.3
>
> What is Orion? Is it possible that it's doing soming funny, with
> the URL stuff? Are you putting the jar files on the path in a 'weird'
> way?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
[Fwd: [Fwd: svg-20001102.dtd not found.]]
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "DL" == Daniel =?iso-8859-1?Q?L=F3pez?= <Daniel> writes:
DL> Nobody in the users list could help me, as it might require an
DL> inside knowledge of batik, so here I go: I'm trying to process an
DL> SVG file inside a servlet to show a JPEG image and after dealing
DL> with a couple of XML parser incompatibility issues, I've stumbled
DL> into this error. When I process the SVG file, a sample file
DL> provided with the batik-1.1rc, I get the error:
DL> java.io.IOException: File
DL> "jndi://D_/Apps/Test/Test/Test/WEB-INF/lib/batik-svg-dom.jar/org/apache/batik/dom/svg/resources/svg-20001102.dtd"
DL> not found. The file batik-svg-dom.jar is in the classpath and it
DL> is exactly in D:/Apps/Test/Test/Test/WEB-INF/lib/, I also checked
DL> to see that the dtd file is in there and indeed, it is.
DL> Any clues?
Well, basically no...
It appears that everything is fine on the Batik side of things.
I've never noticed a 'jndi' protocol descriptor on a URL though. As I
recall the Sun JDK uses 'jar' for a URL like the one above...
DL> Platform is WinNT, Orion1.4.5, JDK1.3
What is Orion? Is it possible that it's doing soming funny, with
the URL stuff? Are you putting the jar files on the path in a 'weird'
way?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org