You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Marshall Flax <ma...@gmail.com> on 2008/03/30 21:05:50 UTC
org.apache.batik.dom.util.SAXDocumentFactory -- svgplugin calling startElement() before createDocument()
Currently, the svgplugin for Eclipse
(http://sourceforge.net/projects/svgplugin/) -- includes Batik 1.5.1.
I'm trying to get it to work against a more up-to-date version of
Batik. What I've found is that essentially no work is required to use
Batik 1.6 with svgplugin, but that 1.7 (and TRUNK) Batik both give a
null-pointer exception in
org.apache.batik.dom.util.SAXDocumentFactory.startElement() --
apparently because createDocument() is never called. This results in a
stack trace (Europa Eclipse, 1.5 OSX 10.4) like
2008-03-30 14:58:45.161 java[4905] [Java CocoaComponent compatibility
mode]: Enabled
2008-03-30 14:58:45.161 java[4905] [Java CocoaComponent compatibility
mode]: Setting timeout for SWT to 0.100000
java.lang.NullPointerException
at org.apache.batik.dom.util.SAXDocumentFactory.startElement(SAXDocumentFactory.java:564)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at com.dlsc.batik.viewer.EclipseSAXSVGDocumentFactory.createDocument(EclipseSAXSVGDocumentFactory.java:41)
at org.apache.batik.dom.util.SAXDocumentFactory.createDocument(SAXDocumentFactory.java:349)
at org.apache.batik.dom.svg.SAXSVGDocumentFactory.createDocument(SAXSVGDocumentFactory.java:200)
at org.apache.batik.dom.svg.SAXSVGDocumentFactory.createSVGDocument(SAXSVGDocumentFactory.java:124)
at org.apache.batik.bridge.DocumentLoader.loadDocument(DocumentLoader.java:106)
at org.apache.batik.swing.svg.SVGDocumentLoader.run(SVGDocumentLoader.java:84)
However, a simple patch like
Index: sources/org/apache/batik/dom/util/SAXDocumentFactory.java
===================================================================
--- sources/org/apache/batik/dom/util/SAXDocumentFactory.java (revision 640199)
+++ sources/org/apache/batik/dom/util/SAXDocumentFactory.java (working copy)
@@ -557,7 +557,7 @@
throw new SAXException(new InterruptedIOException());
}
- if (inProlog) {
+ if (inProlog && parser != null) {
inProlog = false;
try {
isStandalone = parser.getFeature
is sufficient to get it working.
Now here's my question: is SAXDocumentFactory being too picky (i.e. is
the patch correct), or is svgplugin skipping some essential step (i.e.
does svgplugin need to change instead)? I'm afraid I don't understand
either codebase enough to answer this. Any suggestions?
Thanks!
Marshall
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: org.apache.batik.dom.util.SAXDocumentFactory -- svgplugin calling startElement() before createDocument()
Posted by Marshall Flax <ma...@gmail.com>.
Hi again...I apologize for the duplication, but I sent this over the weekend
and it seems to have been somehow overlooked. Any opinions would be greatly
appreciated!
Thanks again.
Marshall
On Sun, Mar 30, 2008 at 3:05 PM, Marshall Flax <ma...@gmail.com>
wrote:
> Currently, the svgplugin for Eclipse
> (http://sourceforge.net/projects/svgplugin/) -- includes Batik 1.5.1.
> I'm trying to get it to work against a more up-to-date version of
> Batik. What I've found is that essentially no work is required to use
> Batik 1.6 with svgplugin, but that 1.7 (and TRUNK) Batik both give a
> null-pointer exception in
> org.apache.batik.dom.util.SAXDocumentFactory.startElement() --
> apparently because createDocument() is never called. This results in a
> stack trace (Europa Eclipse, 1.5 OSX 10.4) like
>
> 2008-03-30 14:58:45.161 java[4905] [Java CocoaComponent compatibility
> mode]: Enabled
> 2008-03-30 14:58:45.161 java[4905] [Java CocoaComponent compatibility
> mode]: Setting timeout for SWT to 0.100000
> java.lang.NullPointerException
> at
> org.apache.batik.dom.util.SAXDocumentFactory.startElement(SAXDocumentFactory.java:564)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
> Source)
> at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> at
> com.dlsc.batik.viewer.EclipseSAXSVGDocumentFactory.createDocument(EclipseSAXSVGDocumentFactory.java:41)
> at
> org.apache.batik.dom.util.SAXDocumentFactory.createDocument(SAXDocumentFactory.java:349)
> at
> org.apache.batik.dom.svg.SAXSVGDocumentFactory.createDocument(SAXSVGDocumentFactory.java:200)
> at
> org.apache.batik.dom.svg.SAXSVGDocumentFactory.createSVGDocument(SAXSVGDocumentFactory.java:124)
> at
> org.apache.batik.bridge.DocumentLoader.loadDocument(DocumentLoader.java:106)
> at
> org.apache.batik.swing.svg.SVGDocumentLoader.run(SVGDocumentLoader.java:84)
>
> However, a simple patch like
> Index: sources/org/apache/batik/dom/util/SAXDocumentFactory.java
> ===================================================================
> --- sources/org/apache/batik/dom/util/SAXDocumentFactory.java (revision
> 640199)
> +++ sources/org/apache/batik/dom/util/SAXDocumentFactory.java (working
> copy)
> @@ -557,7 +557,7 @@
> throw new SAXException(new InterruptedIOException());
> }
>
> - if (inProlog) {
> + if (inProlog && parser != null) {
> inProlog = false;
> try {
> isStandalone = parser.getFeature
>
> is sufficient to get it working.
>
> Now here's my question: is SAXDocumentFactory being too picky (i.e. is
> the patch correct), or is svgplugin skipping some essential step (i.e.
> does svgplugin need to change instead)? I'm afraid I don't understand
> either codebase enough to answer this. Any suggestions?
>
> Thanks!
>
> Marshall
>
Re: org.apache.batik.dom.util.SAXDocumentFactory -- svgplugin calling startElement() before createDocument()
Posted by Marshall Flax <ma...@gmail.com>.
Your patch is of course better. Thank you!
I'll take a look at svgplugin over the weekend and see if I can
propose a patch on that side, which I'm sure the original author will
(if the project is still active) also improve upon :-)
Thanks for Batik!
Marshall
On Thu, Apr 3, 2008 at 6:18 AM, <th...@kodak.com> wrote:
>
>
> Hi Marshall,
>
> "Marshall Flax" <ma...@gmail.com> wrote on 03/30/2008 03:05:50 PM:
>
>
> > org.apache.batik.dom.util.SAXDocumentFactory.startElement() --
> > apparently because createDocument() is never called. This results in a
> > stack trace (Europa Eclipse, 1.5 OSX 10.4) like
>
> It looks like 'EclipseSAXSVGDocumentFactory' is subclassing
> our 'SAXDocumentFactory' and overriding our createDocument and not
> setting the parser to the baseclass. I would consider this
> bad on their part.
>
> That said, I think it would be good to add defensive code.
> In this case I think the fact that isStandalone and xmlVersion
> aren't set should cause no major issues (it looks like those
> values are used to set features on the SVG Document object so
> I'm guessing that this will cause a small non-conformance).
>
> In short I think both code bases should be updated.
>
>
> > However, a simple patch like
>
> I don't like your patch. I would wrap just the two
> 'try' blocks with an 'if':
>
>
> Index: sources/org/apache/batik/dom/util/SAXDocumentFactory.java
> ===================================================================
> --- sources/org/apache/batik/dom/util/SAXDocumentFactory.java (revision
> 636165)
>
> +++ sources/org/apache/batik/dom/util/SAXDocumentFactory.java (working
> copy)
> @@ -559,16 +559,18 @@
>
> if (inProlog) {
>
> inProlog = false;
> - try {
> - isStandalone = parser.getFeature
> - ("http://xml.org/sax/features/is-standalone");
> - } catch (SAXNotRecognizedException ex) {
> + if (parser != null) {
> + try {
> + isStandalone = parser.getFeature
> + ("http://xml.org/sax/features/is-standalone");
> + } catch (SAXNotRecognizedException ex) {
> + }
> + try {
> + xmlVersion = (String) parser.getProperty
> +
> ("http://xml.org/sax/properties/document-xml-version");
> + } catch (SAXNotRecognizedException ex) {
> + }
> }
> - try {
> - xmlVersion = (String) parser.getProperty
> -
> ("http://xml.org/sax/properties/document-xml-version");
> - } catch (SAXNotRecognizedException ex) {
> - }
> }
>
> // Namespaces resolution
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: org.apache.batik.dom.util.SAXDocumentFactory -- svgplugin calling
startElement() before createDocument()
Posted by th...@kodak.com.
Hi Marshall,
"Marshall Flax" <ma...@gmail.com> wrote on 03/30/2008 03:05:50 PM:
> org.apache.batik.dom.util.SAXDocumentFactory.startElement() --
> apparently because createDocument() is never called. This results in a
> stack trace (Europa Eclipse, 1.5 OSX 10.4) like
It looks like 'EclipseSAXSVGDocumentFactory' is subclassing
our 'SAXDocumentFactory' and overriding our createDocument and not
setting the parser to the baseclass. I would consider this
bad on their part.
That said, I think it would be good to add defensive code.
In this case I think the fact that isStandalone and xmlVersion
aren't set should cause no major issues (it looks like those
values are used to set features on the SVG Document object so
I'm guessing that this will cause a small non-conformance).
In short I think both code bases should be updated.
> However, a simple patch like
I don't like your patch. I would wrap just the two
'try' blocks with an 'if':
Index: sources/org/apache/batik/dom/util/SAXDocumentFactory.java
===================================================================
--- sources/org/apache/batik/dom/util/SAXDocumentFactory.java (revision
636165)
+++ sources/org/apache/batik/dom/util/SAXDocumentFactory.java (working
copy)
@@ -559,16 +559,18 @@
if (inProlog) {
inProlog = false;
- try {
- isStandalone = parser.getFeature
- ("http://xml.org/sax/features/is-standalone");
- } catch (SAXNotRecognizedException ex) {
+ if (parser != null) {
+ try {
+ isStandalone = parser.getFeature
+ ("http://xml.org/sax/features/is-standalone");
+ } catch (SAXNotRecognizedException ex) {
+ }
+ try {
+ xmlVersion = (String) parser.getProperty
+
("http://xml.org/sax/properties/document-xml-version");
+ } catch (SAXNotRecognizedException ex) {
+ }
}
- try {
- xmlVersion = (String) parser.getProperty
-
("http://xml.org/sax/properties/document-xml-version");
- } catch (SAXNotRecognizedException ex) {
- }
}
// Namespaces resolution