This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Imagine x.xml: <!DOCTYPE x SYSTEM "./x.dtd> <x/> and x.dtd: <!ELEMENT x EMPTY> Bundled XML non-validating parser reports fatal error.
that is not caused by missing '"' in the example.
This bug blocks at least two XML module features. Please fix it in Crimson or use Xerces instead which does not have such problems.
x
Please explain what kind of problem does it cause. I've tried creating a simple application parsing given xml and it worked w/o single problem when started I'll attach the source. Isn't the problem in your entity resolver?
Created attachment 5650 [details] Testing class that sucessfully parsed the x.xml with added end quote
Created attachment 5653 [details] Previous example using FileObject to get x.xml document.
Petre I have updated your example to use FileObject as source of XML document. Now described problem is reproducible.
Created attachment 5655 [details] Changed test
OK, I've enhanced the test even more to reveal where THE problem is: java.io.IOException: Cannot find: nbfs:QBtmpQBjav/./x.dtd at o.o.execution.NbfsURLConnection.connect(NbfsURLConnection.java:100) at o.o.e.NbfsURLConnection.getInputStream(NbfsURLConnection.java:111) at java.net.URL.openStream(URL.java:798) at org.apache.crimson.parser.InputEntity.init(InputEntity.java:209) I believe that now it is clean where the problem is. The fact that Xerces normalizes the URL before using it as a SID doesn't mean that Crimson is wrong. I'm reassigning this to openide/execution to let them fix the NbfsURLConnection.
Updated summary
Who are they? I suppose you were joking when you put the plural there.
They, David Strupl, the Emperor :-)
in o.o.execution.NbfsURLConnection.connect(..) lines 86-87: FileSystem fsys = repo.findFileSystem(fileSystemName); return (fsys == null) ? null : fsys.findResource (resourceName); So - I think it could be handled in the filesystem.findResource. What do others think? Radek, is this reasonable? - if not please reassign back. Thanks.
I think that the URL itself should be able to cover it, but it doesn't handle it, so we should better catch it in our handler (it is more generic than catching it in FileSystems). But its just my opinion.
I think that filesystems cann handle it, but I think its more confusing than usefull.
Ok, I will do it in NbfsURLConnection.
Fixed in NbfsURLConnection 1.18
*** Issue 8938 has been marked as a duplicate of this issue. ***
verified
Resolved for 3.4.x or earlier, no new info since then -> closing.