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: | I18N - Cannot create session bean with name containing multibyte character - NPE is thrown | ||
---|---|---|---|
Product: | javaee | Reporter: | Marek Grummich <mgrummich> |
Component: | EJB | Assignee: | Martin Adamek <madamek> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | kfrank |
Priority: | P2 | Keywords: | I18N |
Version: | 4.x | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
screenshot
exception Exception_2 |
Description
Marek Grummich
2005-02-09 10:41:11 UTC
Created attachment 20263 [details]
screenshot
Created attachment 20264 [details]
exception
This also happens on solaris in non utf8 asian locales, like ja. In this case, instead of the multibyte that is not correct in editor (see gif), there are ????, which also is a usual sign of encoding issue. My guess only is, since it happens not in utf8 locale, that it could be that code is using utf8 instead of encoding of the locale the user is in, or else that utf8 is ok to use, but its not processing the characters that user typed in as name for the bean as being in the encoding of the locale the user is in. PS - can you see if there is common code that handles other items in new->file->enterprise like other kinds of ejb, etc which might also have this issue ? ken.frank@sun.com ken.frank@sun.com happens for most other file->new items like entity bean, etc in context of an ejb project. This includes web service also. ken.frank@sun.com Problem is that ClassElementFinder is not able to find class in given file which is created from template by XLS transformation. Output is encoded as UTF-8, but input needs to be checked, problem is probably there. Can you look at other encoding handling in this module or parts of it as to processing file/project names or data that would have multibyte to make sure its all done ok (using utf8 or encoding of the users locale as required) ? (including handling of both file creation, modifying saving and rereading on file reopen and on ide restart) Dev team is in process of providing some specs to us on encoding handling for testing; they might be able to give some additional information. ken.frank@sun.com File was really generated with wrong characters. It is fixed now: Checking in EjbGenerationUtil.java; /cvs/j2ee/ejbjarproject/src/org/netbeans/modules/j2ee/ejbjarproject/ejb/wizard/EjbGenerationUtil.java,v <-- EjbGenerationUtil.java new revision: 1.12; previous revision: 1.11 But original exception is still there. In TopClassesCollection.getClass (TopClassesCollection:114) iter.next() returns wrong object (class name has some wrong encoding and is not complete), so I am reassigning this to java How to reproduce: 1) New > Enterprise > EJB Module > Next > Finish 2) on project node New > Session Bean 3) Ejb Name: Výlet, package: foo > Finish 4) Exceptions (ClassElement.forName returns null) General Java project with name Výlet is OK, it never stops on mentioned breakpoint in TopClassesCollection Short note: after exception occured, I close IDE and I am able to run build.xml of generated project without any errors, all classes are compiled fine... There must be a bug in bridge. ClassElement.forName() returns null. Dane, please take a look at it. Thanks BTW: these messages are written to console error: __input:0,0: illegal character: \8482 error: __input:0,0: illegal character: \8482 error: __input:0,0: illegal character: \8482 error: __input:0,0: illegal character: \8482 error: __input:0,0: illegal character: \8482 adding keyword I18N is fine and appreciated, but please leave I18N as first part of synopsis for other tracking purposes. This bug has not roots in TopClassesCollection, neither in hierarchy source bridge at all. The source is badly generated, it contains incorrect characters, thus a class with bad name is created in the jmi java model when the source is parsed. This is the reason, why forName does not work. We should focus on generating of the source file. I was able to build that app, so I guess files are correct ... Maybe we should compare our scenarios. I was able to create Výlet session bean without problems on RH Linux running NetBeans on JDK 1.5.0 with Czech locale (cs_CZ (nb); ISO_8859-2). I tried to repeat my previous/following steps with build 200503101100, jdk1.5.0_02, locale ja_JP (nb): - create a new EJB Module (named without mb chars) - add a new session bean (named New<3xmbchar>Session; package pkg) Error: contents of bean's classes (names) are still corrupted (see source editor) Note: The attached exception I got when I expanded EJB's Local Methods node in the Project view. Created attachment 20783 [details]
Exception_2
I was able to create Výlet session bean without problems on Mandrake Linux running NetBeans on JDK 1.5.0_01 with US locale (en_US (nb); ISO_8859-1). It means I am not able to reproduce my previous problem, something was fixed probably. I will play with japanese now... Since this appears in j2ee project, but not in java, is this issue really in java module area ? (vs j2ee) If so, is this on the list of nb4.1 planned fixes ? We think its needed for i18n/l10n. ken.frank@sun.com The question is - has anybody been able to reproduce this recently? We were trying to investigate this issue but we were not able to since it does not seem to be reproducible (even for the J2EE stuff)... just reproduced on solaris ja locale; we've seen it happen for windows and solaris ja but probably not for solaris ja utf8. and as far as I know, it happens just in j2ee/websvc areas, not for java. ken.frank@sun.com Now it looks to really J2EE problem. Moving back to J2EE. *** Issue 56462 has been marked as a duplicate of this issue. *** Problem doesn't occur with all japanese multibyte characters, only with some subset. I have no idea which subset it is and why this subset is not working. One of problematic characters is first MB character in attached screenshot. If you remove it, everything will work fine. I will investigate more. Fixed. Tested with MB chars in package and bean names, with MBs in database and tables. Everything worked well on Windows with japanese locale. /cvs/j2ee/ejbjarproject/src/org/netbeans/modules/j2ee/ejbjarproject/ejb/wizard/EjbGenerationUtil.java,v <-- EjbGenerationUtil.java; new revision: 1.17; previous revision: 1.16 Verified - pseudolocalized build 200503242007 |