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.

Bug 78303 - I18N - entity class from dbase wont deploy if table or col name has mbyte
Summary: I18N - entity class from dbase wont deploy if table or col name has mbyte
Alias: None
Product: javaee
Classification: Unclassified
Component: Persistence (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: Andrei Badea
Keywords: I18N, RELNOTE
Depends on:
Reported: 2006-06-19 21:20 UTC by Ken Frank
Modified: 2008-07-22 14:06 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

exception (1.12 KB, text/plain)
2006-06-19 21:21 UTC, Ken Frank
image (4.45 KB, image/gif)
2006-06-19 21:22 UTC, Ken Frank
exception bin browser (4.41 KB, text/plain)
2006-07-17 22:38 UTC, Ken Frank
zip of project (60.50 KB, application/octet-stream)
2006-07-18 16:11 UTC, Ken Frank
SJSAS exception during deployment (8.59 KB, text/plain)
2006-08-16 10:16 UTC, Andrei Badea
image (28.35 KB, image/gif)
2006-09-13 16:53 UTC, Ken Frank
oracle (29.95 KB, image/gif)
2006-09-13 18:15 UTC, Ken Frank
derby (67.73 KB, image/gif)
2006-09-13 18:16 UTC, Ken Frank
derby (1.14 MB, image/gif)
2006-09-13 18:17 UTC, Ken Frank

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2006-06-19 21:20:06 UTC
assumption here is that, like with 78286, that for oracle at least, not sure
about derby, that multibyte can be used as a table or column name.

For this, lets just use column name, since that avoids situation of 78286 about
table name with entity class.

this happens on solaris; on windows, can't get yet the oracle schemas to be read
in with entity class from dbase


entity class from dbase, where the table in dbase has a column with mbyte in the
name (put the mbyte first)

jsf pages from ent class

fix the problem with mbyte in each jsp due to the other bug (find/replace)


there is exception, attached and output window shows error related
to the mbyte character (see gif)

for windows, when the entity class from dbase gets the oracle schema,
it shows no tables, yet i am using the same oracle as am using when
using solaris.

and for windows using derby, and using table with column with mbyte
in the name, it does not show the same error msg but exception in browser;
this part needs to be looked at separately since we need to use oracle
as a basis of this issue, and for windows, oracle is not getting the
schema, even though its driver is in gf lib dir.
Comment 1 Ken Frank 2006-06-19 21:21:44 UTC
Created attachment 31175 [details]
Comment 2 Ken Frank 2006-06-19 21:22:09 UTC
Created attachment 31176 [details]
Comment 3 Rochelle Raccah 2006-06-20 19:04:25 UTC
Ken, is the query in orambfromdb.gif written by you or generated by one of the
wizards?  I've checked with our glassfish query expert and he said: "The WHERE
clause of this query looks like that it uses single quotes for the field access
and the named input parameter which is not allowed."

I'm trying to determine if this is user error or generated by NB.
Comment 4 Rochelle Raccah 2006-06-23 00:55:22 UTC
Adding a discussion I had with Ken on this:

Rochelle Raccah wrote:
> But the error message at deployment is due to quotes in the query, so we 
> *do* need to figure them out =)!
> Ken Frank wrote:
>> lets ignore the quotes here - that is not part of this
>> - just taking what nb does - when
>> en used in col name (or table), no error msg seen on deploy; when 
>> mbyte is used; the error msg is seen
>> Rochelle Raccah wrote:
>>> What do you mean "the problem happens when mbyte used and not when en 
>>> used."?  Did you have the quotes there for both?
>>> Ken Frank wrote:
>>>> cant get to iz now - you know, it could be that the quotes thing is 
>>>> something
>>>> i added, trying to workaround it, thinking that mbyte needed quotes -
>>>> so i need to do it again to make sure; but in any case the problem
>>>> happens when mbyte used and not when en used.
Comment 5 Andrei Badea 2006-07-07 14:27:37 UTC
Ken, any more information on this? How did the quotes get there? Were they
generated by NetBeans? Please note this issue is marked as incomplete.
Comment 6 Ken Frank 2006-07-17 22:36:51 UTC
I don't see any more error messages about queries when building or running the
project, just the exception in the new (third) attachment, that is shown in browser.

To clarify:
- this issue is about column with mbyte only; issue about table with mbyte in 78286
- for scenario of new entity class with mbyte as a col name (ie variable in the
java code) - and then jsf pages from ent class (where the ent class name/table
name is en( -- that works ok - in browser I can add or edit columns to the table

- The bug about the jsp files generated from jsf pages from entity class still
exists and workaround needs to be done first - changing the bad mbyte in the
col name (or table name for other scenarios) to the correct mbyte -- this
is some kind of encoding read/write kind of issue on creation of these jsp
Comment 7 Ken Frank 2006-07-17 22:38:38 UTC
Created attachment 31939 [details]
exception bin browser
Comment 8 Andrei Badea 2006-07-18 08:32:29 UTC
The last exception doesn't seem related to I18N. Could you please zip and attach
your project to the issue? Thanks.
Comment 9 Ken Frank 2006-07-18 16:11:59 UTC
Created attachment 31965 [details]
zip of project
Comment 10 Ken Frank 2006-07-18 16:12:30 UTC
zip of the project is attached.
Comment 11 Andrei Badea 2006-08-16 10:16:24 UTC
Created attachment 32983 [details]
SJSAS exception during deployment
Comment 12 Andrei Badea 2006-08-16 10:27:31 UTC
The attached exception is thrown when deploying the project attached by Ken to
SJSAS PE 9.0 FCS. It seems the Chinese characters in the input parameter are not
supported. The BNF grammar for JPQL in the JPA spec doesn't contain a production
for the input_parameter nonterminal (!), so I can't tell if the characters
should be supported or not. But I don't see why they shouldn't be, thus this
looks like a bug in TopLink. This issues will probably be waived for 5.5.

Note for anyone trying to reproduce: the Java files in the attached project are
encoded in Shift-JIS. Best to start NetBeans with

$ netbeans -J-Dfile.encoding=shift-jis
Comment 13 Andrei Badea 2006-08-16 11:23:03 UTC

against GlassFish.
Comment 14 Ken Frank 2006-08-16 16:08:59 UTC
Yes, Japanese characters were used and it was run in ja locale.

Am adding relnote keywd; what are the other bugs you or team has filed on gf
based on some of these recently filed i18n bugs ? I'd like to add that keywd to
those also.
Comment 15 Andrei Badea 2006-09-07 17:02:58 UTC
GlassFish issue 937 was fixed in 9.0 UR1. Can we close this issue?
Comment 16 Pavel Rehak 2006-09-11 13:31:26 UTC
This works just fine for me atm, what about you Ken, satisfied too?
Comment 17 Ken Frank 2006-09-11 19:33:24 UTC
not working for me - get some error msgs in browser; I'll let Pavel
know separately.

Do the enterprise3/modules/ext/toplink/* files need to be the
same as the ones in gf u1 ? they are not; the ones in current
nb still has size of as before -- or are the ones in gf used only ?
Comment 18 Andrei Badea 2006-09-13 10:43:24 UTC
Stepan agreed to test the GF fix.

Ken, please post any error message to the issue. Do you get the exception in
desc12, or something else? If the latter then please file a separate issue.
Comment 19 Ken Frank 2006-09-13 16:51:56 UTC
attached are some browser error pages from using with oracle and derby,
with mbyte column names as per scenario of this issue.

Pavel, please provide more details of your steps and observations on windows;
I am on solaris.
Comment 20 Ken Frank 2006-09-13 16:53:14 UTC
Created attachment 33888 [details]
Comment 21 Andrei Badea 2006-09-13 18:07:47 UTC
That is another exception than the one in desc12, which is what is being solved
in this issue. Please file a separate issue for it and attach the full exception
from the server logs, not an image. I also don't see anything related to Derby
in the attached image.
Comment 22 Ken Frank 2006-09-13 18:15:51 UTC
Created attachment 33890 [details]
Comment 23 Ken Frank 2006-09-13 18:16:47 UTC
Created attachment 33891 [details]
Comment 24 Ken Frank 2006-09-13 18:17:35 UTC
Created attachment 33892 [details]
Comment 25 Andrei Badea 2006-09-15 15:10:09 UTC
The exceptions in orambcolent.gif, orambcolfroment.gif and derbymbcolfroment.gif
are not related to this isssue. Please file two new issues: one for
orambcolent.gif and one for the other two images.

The exception in derbymbcolfromentdb.gif, however, seems to be the one that we
are dealing with in this issue. It is weird, because I can't reproduce it with
GF 9.0 UR1 Build 10. Which version did you use? Could you please reproduce the
exception again and attach the server log? Thanks.
Comment 26 Andrei Badea 2006-09-19 15:17:49 UTC
Taking back.
Comment 27 Andrei Badea 2006-09-19 15:21:26 UTC
I belive this was fixed, so marking as such. Please reopen if you can still
reproduce in a build of GF v1 UR1 newer than September 7.
Comment 28 kaa 2008-07-22 14:06:25 UTC
Product Version: NetBeans IDE Dev (Build 20080721233246)
Java: 1.6.0_06; Java HotSpot(TM) Client VM 10.0-b22
System: Windows XP version 5.1 running on x86; MS932; ja_JP (nb)

I used a table with mbyte in its column and WebApp with JSF framework.

Win-31j project encoding:
Entity class was generated ok. Deployment of the app was ok.
jsf pages from ent class were generated ok.
Files have win-31j encoding.

UTF-8 project encoding:
Entity class was generated ok. Deployment of the app was ok.
jsf pages from ent class were generated ok. Deployment of the app was also ok.
Files have UTF-8 encoding.