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.
Description: BuildID : RC2 & RC5 JDK : 1.4FCS OS : Solaris9 Ja Find attached Gif for your reference. Pls.view the gif to see garbage Multibyte String in Output window. To Reproduce : - Mount "application" directory as local directory,load Wizard "New Wizard - Session Bean" - Create <multibyte>EJB Session Bean - Right Click,<multibyte>EJB Bean node choose "Create NewEJB Test Application" from the context menu. - Choose default values,click OK - Highlight the <multibyte>J2EE Application,Right click, choose "Export Application EAR File "from the Context menu - Choose default values,Click OK - Highlight the <Multibyte>EAR File created in IDE,Right click,choose"Extract Ear File" from the context menu.. - The <multibyte>Ear file is extracted as import-<multibyte> in the IDE. - Highlight import-<multibyte>,Rightclick choose "Find" from the context menu. - Enter <multibyte> String ,as Substring to search for - Check "Use this criterion for search" to enable Search button - Click Search - Matching nodes appear as Search results - Click "Show All Details" button The following below exception is thrown in the console,and also Multibyte appears as garbage in the output window. Exception : ******* Failed to create the XML-DOM Document. Check your XML to make sure it is correct. org.xml.sax.SAXParseException: at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3182) at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3170) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:501) at org.apache.crimson.parser.Parser2.parse(Parser2.java:305) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:442) at org.apache.crimson.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:185) at org.netbeans.modules.schema2beans.GraphManager.createXmlDocument(GraphManager.java:711) at org.netbeans.modules.schema2beans.GraphManager.createXmlDocument(GraphManager.java:675) at org.netbeans.modules.schema2beans.GraphManager.createXmlDocument(GraphManager.java:642) at com.sun.forte4j.j2ee.appsrv.RI.dd.J2eeRiSpecificInformation.createGraph(J2eeRiSpecificInformation.java:498) at com.sun.forte4j.j2ee.appsrv.RI.dd.J2eeRiSpecificInformation.createGraph(J2eeRiSpecificInformation.java:492) at com.sun.forte4j.j2ee.appsrv.RI.RIAppAsmItem.<init>(RIAppAsmItem.java:68) at com.sun.forte4j.j2ee.appsrv.RI.RIAppAsmSupport.getCustomData(RIAppAsmSupport.java:54) at com.sun.forte4j.j2ee.lib.util.AppServerSupport.addServerCustomData(AppServerSupport.java:271) at com.sun.forte4j.j2ee.lib.util.AppServerSupport.initializeCustomData(AppServerSupport.java:105) at com.sun.forte4j.j2ee.lib.util.AppServerSupport.addTabsToSheet(AppServerSupport.java:716) at com.sun.forte4j.j2ee.appasm.AsmDataObject.addAppsrvTabs(AsmDataObject.java:2175) at com.sun.forte4j.j2ee.appasm.AsmDescNodeImpl.createSheet(AsmDescNodeImpl.java:285) at com.sun.forte4j.j2ee.appasm.AsmMainNode.createSheet(AsmMainNode.java:121) at org.openide.nodes.AbstractNode.getSheet(AbstractNode.java:315) at org.openide.nodes.AbstractNode.getPropertySets(AbstractNode.java:327) at org.openide.nodes.FilterNode.getPropertySets(FilterNode.java:419) at org.openide.explorer.propertysheet.PropertySheet.refreshPropertySheet(PropertySheet.java:449) at org.openide.explorer.propertysheet.PropertySheet.access$1100(PropertySheet.java:52) at org.openide.explorer.propertysheet.PropertySheet$3.run(PropertySheet.java:638) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178) at java.awt.EventQueue.dispatchEvent(EventQueue.java:443) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:130) at java.awt.EventDispatchThread.run(EventDispatchThread.java:98) The same operation when performed in an English EJB displays 8 matching nodes,and show details does fine. Evaluation: Could not reproduce this on Solaris Ja (because the mbcs string is not matched in UTF-8 encoded xml files) or Ja-UTF. With Ja-Unicode (UTF), the string is match and ShowAllDetails display them correctly. No exception/stack strace is seen. So far this not RI plugin problem. Now, displaying garbage for UTF-8 encoded string on Windows and Linux might be bug in either jdk or netbeans open source modules 'utilities' (search) or 'core'. xxx@xxxx 2002-09-13 A comment.
Hello Reporter, I investigate this issue, right now. But, I feel that, this issue may not be "I18N" problem. I tried to repeat your process. And, garbage characters are appeared in Output Window. But, these are not incorrect japanese characters, these may be "Dumped Binary File". And, garbage characters are appeared from war file which name has only ascii characters. (e.g. import-test_TestApp.ear) If I misunderstanding your report, Please tell me the correct way. Thank you - Hiroshi
Created attachment 7771 [details] garbage characters in output window.
Hello Naveen, I found that, I was misunderstanding your report. I reached to similar exception and same garbage japanese characters. This issue is certainly reappeared in japanese environment. I'm sorry to you spend unnecessary time. Thank you - Hiroshi.
Created attachment 7783 [details] White square is garbage japanese characters.
Hello Naveen, I investigate this issue. And, here is one new tip about this. This garbage Multibyte Characters are consists in "<multibyte>_TestApp.appasm" file. And, Multibyte Characters are encoded with UTF-8 in this file. Thus, You must "decode" precisely to indicate Multibyte Characters precisely. Hiroshi
Consistent use of the I18N keyword.
I think this is rather some encoding issue than i18n problem. We'll look at it for NB 4.0. Hiroshi - if you were able to reproduce this, don't you remember if the garbage was shown only in the output window and not in the editor when the file was opened? Thanks.
Let's keep the i18n keyword anyway...
Doubtful this is reproducible with the new output window. Looks suspiciously like somebody was casting chars as bytes and writing them into a byte[] that really represented UTF-16 char data.
This should not happen any more because: - binary files should are skipped during search - see issues: bug #44310 - Search should ignore nonsharable files bug #46165 - Search should skip files which are hidden acc. to VisibilityQuery - the code for the output window has changed significantly and the author of the change is pretty confident it should fix the problem Please verify as soon as possible.