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