Bug 30983 - DocumentBuilder.parse throws exception
Summary: DocumentBuilder.parse throws exception
Status: RESOLVED FIXED
Alias: None
Product: classpath
Classification: Unclassified
Component: xml (show other bugs)
Version: unspecified
: P3 normal
Target Milestone: ---
Assignee: chris burdess
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-27 16:24 UTC by Andrew Overholt
Modified: 2007-03-26 19:03 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-02-28 09:21:00


Attachments
Test case (xml file to come) (434 bytes, text/x-java)
2007-02-27 16:29 UTC, Andrew Overholt
Details
xml file that gives error (331 bytes, text/xml)
2007-02-27 16:30 UTC, Andrew Overholt
Details
Patch (655 bytes, patch)
2007-02-28 09:20 UTC, chris burdess
Details | Diff
New patch (2.05 KB, patch)
2007-03-07 11:20 UTC, chris burdess
Details | Diff
More problems fixed (2.38 KB, patch)
2007-03-07 11:45 UTC, chris burdess
Details | Diff
Improved test case (423 bytes, text/plain)
2007-03-08 09:36 UTC, Gary Benson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Overholt 2007-02-27 16:24:18 UTC
With the test casethat I will attach, I get the following stacktrace with gcj (basically the generics branch).  With the BEA JVM, I get no output.

Exception in thread "main" gnu.xml.dom.ls.DomLSException: no root element: U+ffffffff
   at gnu.xml.dom.ls.DomLSParser.doParse(libgcj.so.7rh)
   at gnu.xml.dom.ls.DomLSParser.parse(libgcj.so.7rh)
   at gnu.xml.dom.ls.DomLSParser.parseURI(libgcj.so.7rh)
   at gnu.xml.dom.DomDocumentBuilder.parse(libgcj.so.7rh)
   at TestXMLParse.main(TestXMLParse.java:26)
Caused by: org.xml.sax.SAXParseException: no root element: U+ffffffff
   at gnu.xml.stream.SAXParser.parse(libgcj.so.7rh)
   at gnu.xml.dom.ls.DomLSParser.doParse(libgcj.so.7rh)
   ...4 more
Caused by: javax.xml.stream.XMLStreamException: no root element: U+ffffffff
   at gnu.xml.stream.XMLParser.error(libgcj.so.7rh)
   at gnu.xml.stream.XMLParser.error(libgcj.so.7rh)
   at gnu.xml.stream.XMLParser.next(libgcj.so.7rh)
   at gnu.xml.stream.XMLParser.hasNext(libgcj.so.7rh)
   at gnu.xml.stream.SAXParser.parse(libgcj.so.7rh)
   ...5 more
Comment 1 Andrew Overholt 2007-02-27 16:29:46 UTC
Created attachment 13121 [details]
Test case (xml file to come)
Comment 2 Andrew Overholt 2007-02-27 16:30:25 UTC
Created attachment 13122 [details]
xml file that gives error

Put this file in the same place from which you run the test case.
Comment 3 chris burdess 2007-02-28 09:20:27 UTC
Created attachment 13124 [details]
Patch
Comment 4 chris burdess 2007-02-28 09:21:00 UTC
Please test with the attached patch and let me know if that solves your problem.
Comment 5 Tom Tromey 2007-03-05 16:10:12 UTC
I tried this patch and it changes the error to something different:

Exception in thread "main" gnu.xml.dom.ls.DomLSException: newsExtensionContent.xml:21
   at gnu.xml.dom.ls.DomLSParser.getInputSource(DomLSParser.java:409)
   at gnu.xml.dom.ls.DomLSParser.doParse(DomLSParser.java:254)
   at gnu.xml.dom.ls.DomLSParser.parse(DomLSParser.java:161)
   at gnu.xml.dom.ls.DomLSParser.parseURI(DomLSParser.java:177)
   at gnu.xml.dom.DomDocumentBuilder.parse(DomDocumentBuilder.java:140)
   at TestXMLParse.main(TestXMLParse.java:26)
Caused by: java.net.UnknownHostException: newsExtensionContent.xml:21
   at gnu.java.net.PlainSocketImpl.connect(natPlainSocketImpl.cc:150)
   at java.net.Socket.connect(Socket.java:437)
   at java.net.Socket.connect(Socket.java:397)
   at gnu.java.net.protocol.ftp.FTPConnection.<init>(FTPConnection.java:253)
   at gnu.java.net.protocol.ftp.FTPConnection.<init>(FTPConnection.java:221)
   at gnu.java.net.protocol.ftp.FTPURLConnection.connect(FTPURLConnection.java:119)
   at gnu.java.net.protocol.ftp.FTPURLConnection.getInputStream(FTPURLConnection.java:163)
   at java.net.URL.openStream(URL.java:736)
   at gnu.xml.dom.ls.DomLSParser.getInputSource(DomLSParser.java:402)
   ...5 more
Comment 6 chris burdess 2007-03-07 11:20:54 UTC
Created attachment 13159 [details]
New patch

New patch that runs this test successfully
Comment 7 chris burdess 2007-03-07 11:45:15 UTC
Created attachment 13160 [details]
More problems fixed
Comment 8 Gary Benson 2007-03-07 15:59:53 UTC
Chris, your patches look like they're for http://developer.classpath.org/pipermail/classpath/2007-February/001882.html.  This isn't the same issue is it?
Comment 9 chris burdess 2007-03-07 16:20:44 UTC
I overhauled the feature names as part of that work, so it becomes related.

I'm having problems testing this ATM due to jamvm crashes on my test arch (powerpc64) so I'd rather try and recreate a complete patched environment for others to try.

There are some minor bugs in the XML framework which the patch should resolve. I don't know if we can really solve the problem as it stands since the file: URL supplied in the test is clearly malformed. But feedback would be welcome.
Comment 10 Gary Benson 2007-03-07 16:31:06 UTC
Did you see that I fixed the xerces thing?  There was a missing file that caused a weird half-classpath, half-xerces mix.  FWIW you can't run that way even with the changed feature names because there are other incompatibilities; it only works with Sun because Sun's JAXP implementation _is_ xerces, so the half-and-half mix there is xerces and xerces.  Which is a long-winded way of saying that you don't need to rename the features if you don't want to.
Comment 11 chris burdess 2007-03-07 16:37:56 UTC
Yep, I saw your patch, but I still need to change the feature names to match those in the DOM spec.
Comment 12 Gary Benson 2007-03-07 16:56:57 UTC
May I suggest that any parameter not in
http://java.sun.com/j2se/1.5.0/docs/api/org/w3c/dom/DOMConfiguration.html
be prefixed with "gnu-" or something so it's obvious which ones are ours?
Comment 13 Gary Benson 2007-03-08 09:34:40 UTC
So I tried the testcase on IBM and like BEA it produced no output, but it turned out that an exception very similar to tromey's was being eaten:

  java.net.UnknownHostException: newsExtensionContent.xml
        at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:215)
        at java.net.Socket.connect(Socket.java:536)
        at java.net.Socket.connect(Socket.java:486)
        at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
        at sun.net.NetworkClient.openServer(NetworkClient.java:141)
        at sun.net.ftp.FtpClient.openServer(FtpClient.java:503)
        at sun.net.ftp.FtpClient.openServer(FtpClient.java:490)
        ...

It seems tromey's exception is the "correct" response to the broken URL.  However, we only get it because the patch subtly disables the entity resolver, and I can't see how that can be the right thing to do.
Comment 14 Gary Benson 2007-03-08 09:36:41 UTC
Created attachment 13168 [details]
Improved test case

Testcase that a) does not eat exceptions and b) has a valid URL.
Comment 15 cvs-commit@developer.classpath.org 2007-03-08 11:17:01 UTC
Subject: Bug 30983

CVSROOT:	/cvsroot/classpath
Module name:	classpath
Changes by:	Gary Benson <gbenson>	07/03/08 11:16:32

Modified files:
	.              : ChangeLog 
	gnu/xml/dom/ls : DomLSParser.java 

Log message:
	2007-03-08  Gary Benson  <gbenson@redhat.com>
	
		PR classpath/30983:
		* gnu/xml/dom/ls/DomLSParser.java (getInputSource):
		Do not use the entity resolver to resolve the top-level document.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&r1=1.9147&r2=1.9148
http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/xml/dom/ls/DomLSParser.java?cvsroot=classpath&r1=1.5&r2=1.6



Comment 17 gary@gcc.gnu.org 2007-03-08 16:33:52 UTC
Subject: Bug 30983

Author: gary
Date: Thu Mar  8 16:33:40 2007
New Revision: 122700

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122700
Log:
2007-03-08  Gary Benson  <gbenson@redhat.com>

	PR classpath/30983:
	* gnu/xml/dom/ls/DomLSParser.java (getInputSource):
	Do not use the entity resolver to resolve the top-level document.


Modified:
    trunk/libjava/classpath/ChangeLog.gcj
    trunk/libjava/classpath/gnu/xml/dom/ls/DomLSParser.java
    trunk/libjava/classpath/lib/gnu/xml/dom/ls/DomLSParser.class

Comment 18 gary@gcc.gnu.org 2007-03-08 17:02:29 UTC
Subject: Bug 30983

Author: gary
Date: Thu Mar  8 17:00:24 2007
New Revision: 122704

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122704
Log:
2007-03-08  Gary Benson  <gbenson@redhat.com>

	PR classpath/30983:
	* gnu/xml/dom/ls/DomLSParser.java (getInputSource):
	Do not use the entity resolver to resolve the top-level document.


Modified:
    branches/redhat/gcc-4_1-branch/libjava/classpath/ChangeLog.gcj
    branches/redhat/gcc-4_1-branch/libjava/classpath/gnu/xml/dom/ls/DomLSParser.java

Comment 19 Andrew Overholt 2007-03-26 19:03:10 UTC
gcj in Fedora rawhide (libgcj-4.1.2-5) no longer throws an exception with Eclipse 3.3M5's welcome screen.  Thanks.