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
Created attachment 13121 [details] Test case (xml file to come)
Created attachment 13122 [details] xml file that gives error Put this file in the same place from which you run the test case.
Created attachment 13124 [details] Patch
Please test with the attached patch and let me know if that solves your problem.
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
Created attachment 13159 [details] New patch New patch that runs this test successfully
Created attachment 13160 [details] More problems fixed
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?
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.
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.
Yep, I saw your patch, but I still need to change the feature names to match those in the DOM spec.
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?
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.
Created attachment 13168 [details] Improved test case Testcase that a) does not eat exceptions and b) has a valid URL.
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
http://developer.classpath.org/pipermail/classpath-patches/2007-March/005152.html
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
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
gcj in Fedora rawhide (libgcj-4.1.2-5) no longer throws an exception with Eclipse 3.3M5's welcome screen. Thanks.