Bug 76583

the second gif on left shows the correct mbyte for the table and col names in
the db explorer.

Created attachment 30511 [details]
image

Created attachment 30512 [details]
image

Related to use of multibyte, assumptions are that mbyte
can be used in new j2ee persistence and other new areas for 55
such as in names of projects, names of persistence units,
names of java files and classes, etc.

can you look at
the new code and functionality to make sure its
ok and let us know if there is some restriction
based on persistence or other specs related to j2ee5 ?

ken.frank@sun.com

I guess the best solution would be to generate the jsf pages with I18N, probably
using <f:loadBundle ..> and put the messages into a bundle. I think that
generating these pages with I18N instead of inline messages would be nice. But I
am little bit hessitant if this is not more like a new feature for 5.5 then a
bugfix. The code generated by this wizard should be a simple "get me started"
code, not an attempt to solve all concievable issues of web app development.
Note that we currently do not support I18N of JSP pages. For example EL code
completion does not take <f:loadBundle> into effect.
I am not saying a strict NO, I am just raising questions. Any comments?

Also, is there any other simpler way to solve this problem (e.g. just generating
the whole pages in japanese)?

Thanks for bringing this up, Ken.

I don't think this issue is related to user doing i18n of their app
in context of using their own bundle files -- it would be great to do this
and there is an RFE on providing some equivalent of the i18n wizards for jsp
or other file types than java.

But this issue is not about that - its just the case where mbyte is 
used in name of some table or column, or perhaps in project name,
persistence unit name, etc -- anywhere where it might show up
in generated jsp or java files when user is doing things
with new persistence features and creating entity class,
entity class from dbase, jsf from dbase, etc.
(and thats why in description I also asked for feedback 
if any restrictions to using mbyte in project names,
persistence unit name, etc related to this new functionality --
please reply on that.

ALSO, can you elaborate more on what is meant by 
- we don't support i18n of jsp pages -- it just refers
to the code completion not happening for it, not that user
can't do it themselves like using the load bundle, and that
it would work ? If its just this, I can file RFE;
if it won't work at all, seems like a separate issue.

ken.frank@sun.com

This issue also means user cannot deploy/run with an entity class that
has mbyte as a column or table name (ie name of class for table or name
of variable as column -- since the jsp does not have the mbyte correctly,
it means the build or deploy will not work, since the mbyte values in the jsp
dont match those in the java file

I replaced the mbyte in jsp with the correct values as to encoding and
it worked - a table with a column with mbyte was created in dbase
(not sure if a table with mbyte table name is working)

but even for derby, if mbyte not allowed in table or col name, it is allowed
in oracle or other dbases

--> so can this be fixed soon for beta2 - this is not related to a localized
release since has nothing at all to do with localization, this is an i18n
encoding issue.

ken.frank@sun.com

Hi Ken, how important is to fix this for NetBeans 5.5? Is it a common scenario
to have multibyte table/column names in a database? Do all databases support
this, and which ones do not? How often is this used in practice? Thanks.

Will try to answer some of Petr's questions:

"Hi Ken, how important is to fix this for NetBeans 5.5? Is it a common scenario
to have multibyte table/column names in a database? Do all databases support
this, and which ones do not? How often is this used in practice? Thanks."


As to use of mbyte in table/column names, I think as we get a wider audience for
the fucntionality, there will be more users in other countries and thus more
that will want to use mbyte in table or column names (the topic of this bug and
other related one is column names, which I think would be more used).

That is, table and column names are often chosen to relate to the data
in them, and since we know data can and are having mbyte, and if the
dbase itself supports mbyte in table and/or column name, then nb should
also. (we see that at least oracle and javadb allow this, think that others
do but would need to look at it but that shouldn't block this issue since we
know at least these 2 db allow it and are 2 of our supt db)

Also, we didn't see problems when create entity class then adding mbyte
as variable, which will become column name in db -- so it seems that the
sort of reverese - create ent class from db (which is where problem in this
issue seen) should supprt mbyte also.

Also, for this particular issue, about the way the mbyte is shown/encoded
in List.jsp, etc - it seems that at least that part should be fixed
in any case since that is just encoding situation; and users might
separately modify the jsp files separeately to have mbyte.

ken.frank@sun.com


"

Similarly to issue 78286, since we are not aware of real world apps that use
multibyte table names today, and the fix is controversial and non-trivial, I am
requesting a waiver for this issue.

The workaround is either
- renaming database columns/tables not to use multibyte, or
- correcting the generated JSP pages

The waiver is approved.

Feature is dropped in 6.0