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 - entity class with mbyte name (= table name) does not work | ||
---|---|---|---|
Product: | javaee | Reporter: | Ken Frank <kfrank> |
Component: | JSF | Assignee: | Andrei Badea <abadea> |
Status: | RESOLVED INVALID | ||
Severity: | blocker | CC: | abadea, kaa, pjiricka, ppisl, prehak, sunlit |
Priority: | P3 | Keywords: | I18N |
Version: | 5.x | ||
Hardware: | Sun | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | image |
Description
Ken Frank
2006-06-19 20:21:41 UTC
Created attachment 31172 [details]
image
I assume the problem is that the generator uses table name for a folder name which in turn is being used as a URL and this last part does not work. Any suggestions for how to solve this? Would it be acceptable to generate different folder name? Or should I try to escape the string used for URL so that it could point to the folder with multibyte name (is that possible)? Thanks for any ideas. I can't think of a way to reliably generate a meaningful folder name. Replacing non-us-ascii characters with _ would probably not work for names in which all characters are non-ascii (Chinese, etc.). URL-encoding the folder names using UTF-8 as the character-to-byte encoding would be better if it proves to work. UTF-8 is not specified by the HTTP 1.1 spec as the default request encoding (no encoding is, so at least some servers will use ISO-8859-1). I have no idea if if the servers we support use UTF-8 when parsing the request. Addtional info - the table is created in the dbase however (at least for derby) , and data can be added to it (mb table name, en col name in this case, since this issue is about table names, not col names, see 78303 for one about that. 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 names in a database? Do all databases support this, and which ones do not? Thanks. Answering Petr's questions from other comments: "Hi Ken, how important is to fix this for NetBeans 5.5? Is it a common scenario to have multibyte table names in a database? Do all databases support this, and which ones do not? 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, it is legal in java to have class name with mbyte in it; so by not allowing table name with mbyte, it is a restriction on use of java. Thus I think that it will be helpful to fix this. ken.frank@sun.com Ok, so it sounds like this is something that people may in the future potentially do, but we don't have current real world examples of databases with multibyte column/table names. Also, since this is a difficult and time consuming fix, and the desired solution is not clear, 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. Downgrading to P3, since this hasn't have any duplicates so far, and the user impact is low. Not clear what the right solution is, but it probably needs to use FileEncodingQuery. how about not allowing mbyte as the class name, with a warning in the wizard on that pane and not allow wizard to proceed until class name does not have multibyte ? This seems to be easier kind of fix and allows to avoid the problem and if there is additional user input, then actual fix could be considered. ken.frank@sun.com The whole wizard will be dropped from 6.0. Since there is no JSF from Entity Class wizard from in 6.0, there is no bug, so closing. |