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.
| Summary: | Complete failure of module system when using non-ASCII installation dir | ||
|---|---|---|---|
| Product: | platform | Reporter: | flyr <flyr> |
| Component: | Module System | Assignee: | Jesse Glick <jglick> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | anebuzelsky, mfukala, mmirilovic |
| Priority: | P2 | Keywords: | I18N |
| Version: | 4.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: | This is the log for my problem. | ||
|
Description
flyr
2005-10-17 10:33:18 UTC
Created attachment 26019 [details]
This is the log for my problem.
Can you please let me know what is the problem? The informational exceptions? Which one? Does it cause any real problems (sg. not working)? Without this information I cannot help you. Can you try to use 5.0 beta and let us know whether the problem still appears? This is likely not a problem of xml module. Reassigning to core for reevaluation. Marek, I would ask you to don't this kind of "resolving" again. The Core team *IS NOT The One You Can Send Any Issue For Evaluation!* Actually I am not sure who causes this exception. Probably projects can do better job to check availability/accessibility of the file before start to parse. Feel free to reassigne. java.net.MalformedURLException: no protocol: XMLEditor.ent .... at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse (AbstractSAXParser.java:1168) at org.netbeans.core.projects.cache.ParsingLayerCacheManager.createRoot (ParsingLayerCacheManager.java:123) Marian, although I fully agree that core is not "evaluation" component, this issue really belongs there. The org.netbeans.core.projects is part of the core, not part of the project system. (It seems to me that the 4.1's org.netbeans.core.projects.cache.ParsingLayerCacheManager is core/startup/src/org/netbeans/core/startup/layers/ParsingLayerCacheManager.java in 5.0) I would guess this is caused by either corrupt IDE installation or some corrupt/invalid module installed in the IDE. Probably caused by use of Chinese characters in installation dir; maybe there is a mismatch in encoding between what Java expects and what the filesystem is using. Very likely specific to Windows and specific to whatever encoding is set as system default, since this is below the level that a Java app can know about. So WORKSFORME unless steps to reproduce are provided that can be followed on a clean Windows machine. More helpful summary... Surprisingly (to me at least) I can reproduce on my UTF-8 Linux system just by running the IDE from an installation dir "/tmp/sko\u0159ice". On 1.5 or 1.6; 1.4 is OK. XML parser problem I suppose. mfukala: in fact the bug *is* caused by the usage of entity includes in the xml/text-edit module's layer. However these should not be illegal. I can confirm that this is a regression in JDK 5.0 which I will file. Will work around it by removing entity includes from xml/text-edit; they are unnecessary. JDK bug filed. I also found a workaround that could be used if we cared about supporting entity includes in third-party modules: just set an entity resolver that does what the default one is supposed to do to begin with, i.e. resolve relative URIs. However I will not do that for now, since it just messes up the code to work around a JDK bug that should get fixed eventually anyway. Removing DTDEditor.ent; /cvs/xml/text-edit/src/org/netbeans/modules/xml/text/resources/DTDEditor.ent,v <-- DTDEditor.ent new revision: delete; previous revision: 1.6 done Removing XMLEditor.ent; /cvs/xml/text-edit/src/org/netbeans/modules/xml/text/resources/XMLEditor.ent,v <-- XMLEditor.ent new revision: delete; previous revision: 1.15 done Checking in mf-layer.xml; /cvs/xml/text-edit/src/org/netbeans/modules/xml/text/resources/mf-layer.xml,v <-- mf-layer.xml new revision: 1.25; previous revision: 1.24 done Workaround for users of previous builds should be to install NetBeans in a directory whose name contains only ASCII characters. Root bug reportedly fixed in JDK 6 b62, so will not bother with any further workarounds, I guess. (I don't know if the fix will be backported to a JDK 5 update release or not.) I'd like to verify this if still applicable for nb6 - what is the details of the issue and is it still related to a jdk bug ? (If its about installing nb in a dir that has multibyte or non ascii, from looking at other issues and release notes, it seems that is not supported - is this issue related to that ? ken.frank@sun.com I assume it is still applicable to NB 6. It is still at root a JDK bug, which is I presume still fixed in JDK 6. It is indeed about installing NB in a dir using non-ASCII chars, which ought to be supported if possible. |