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.
Create a new update center with URL http://www.netbeans.org/updates/alpha/dev_alpha_daily.xml (Workaround for issue #32774.) Try to connect to it. You can't; the parsing fails for no reason: Annotation: URL: http://www.netbeans.org/updates/alpha/dev_alpha_daily.xml Annotation: Parse error in file http://www.netbeans.org/updates/alpha/dev_alpha_daily.ent line 2,512 column -1 (PUBLIC null) org.xml.sax.SAXParseException: Character conversion error: "Illegal ASCII character, 0xe3" (line number may be too low). at org.apache.crimson.parser.InputEntity.fatal(InputEntity.java:1100) Actually in dev_alpha_daily.ent, the character in question is further down, in the Japanese localization of the Ant module. Note that dev_alpha_daily.ent is included from dev_alpha_daily.xml as an entity include, and correctly includes the declaration <?xml version="1.0" encoding="UTF-8"?> at the top. Nonetheless, Crimson seems to be too stupid to understand this and is apparently attempting to parse it as ASCII. If you connect to e.g.: file:/space/src/nb_all/www/www/updates/alpha/dev_alpha_daily.xml i.e. the same URL on local disk, then it is OK. (Except for issue #33095, but that is not fatal - other modules are still displayed.) It is only the http: version of the file that is unparsable, for whatever reason. This seems to be a Crimson bug. (I am using JDK 1.4.2 b19 on Linux.) Xerces seems to work correctly, so the workaround is to add this to your $nbhome/bin/ide.cfg: -J-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl Another workaround be to inline the entity includes on the website, I suppose - I have not tried it.
Created attachment 10051 [details] Stack trace
Yes it looks like a bug in Crimson. Seems like the only difference between file:// and http:// connection is that the first one retuns contentType unknown the second one returns text/xml. Making the server to return proper encoding could help but is probably impossible to achieve on NetBeans server. I've tested Jesses second proposal for not using !ENTITY in the XML file and it works. I'll try to organize this for the NetBeans server. I don't put some hacks into the Au client to obtain xerces instead of crimson.
Adding Robert Novak on CC. The NetBeans AU center should avoid using XML entities. This will workaround the bug in the Crimson parser. However the issue with crimson should be solved somehow. Not sure how.
I think Ruda actually handles the daily alpha build. Funny about the Content-Type - text/xml is the *correct* type for the *.ent file. Hmm. Maybe if the Crimson problem can be reproduced in a standalone app, file a bug on xml.apache.org.
*** Issue 33264 has been marked as a duplicate of this issue. ***
I suggest this issue be P2, bacause it blocks me connecting to NetBeans Alpha AU server
Need not be P2. This bug has already been worked around, as Petr mentioned, and is lower priority. Issue #33264 is unrelated.
What's the issue # of a workaround?
Maxym, I guess, that the workaround is to not use reference to external !ENTITY within the .xml file.
*** Issue 7946 has been marked as a duplicate of this issue. ***
reassigne to Jirka - new owner of autoupdate
Seems as WONTFIX. Crimson is not used in AU anymore. Reopen if I'm wrong.
Oops, I'm wrong, openide.xml/XMLUtil.parse() returns crimson still. I reopen it. It's this bug still anywhere visible?
It is presumably still visible if you have an UC XML file using entity includes. Currently netbeans.org does not but someone else may well try it.
Probably not high priority.
I guess this won't be fixed for NB4.0 , please evaluate again.
I feel it's problem won't be tracked no longer. No other bugs don't depend on this. Closed as WONTFIX.
x