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.
this was not happening a few weeks ago. create desktop dbase app in the following situations: if path to project dir has multibyte, whether its name of project dir or dir above that - then when run the java desktop dbase app project, get these exceptions. if path does not, then the desktop app runs ok. In this case the dir with mbyte is the dir above the project dir, thats why there is no mbyte path mentioned in the exception; in attached exception is example of part of exception msg when there is mbyte in the project name/dir. happens on solaris or windows with pseudo localized in ja locale or in zh locale without pseudo, for example using utf8 or euc-jp project encoding running with the java -jar command line in a terminal, same errors (output does claim it builds) am not using any dbase data that has mbyte in it, or in names of table or columns.
Created attachment 51368 [details] file
Created attachment 51369 [details] file
attachment named firstrun is about: all desktop app db project, at least on solaris, seems to need to c lean and rebuild as below before run since get this msg in output window if try to run it first whether the project has mbyte in path to it or not. I don't know if this is related to this issue; I think it happened on solaris in en locale also. ken.frank@sun.com
I am sorry, but I don't understand what you did exactly and what build you used. Please, provide build number and _exact_ steps to reproduce this issue. Don't forget to mention actual x expected behavior. Also, please, specify clearly whether this issue has anything to do with multibyte characters in path or not. Thank you in advance.
I think details were elaborated but will try again 1019 build solaris sparc pseudo localized nb in ja locale, though it happens with non pseudo localized in chinese locale happens on windows also happens whether project uses default proj encoding of utf-8 or if its changed to euc-jp for ja solaris, for example (when project encoding is changed, a completely new project is used, not the same one) 1. create javadesktop db project that has multibyte in the path to it; in this case it was the netbeans project dir but also happens if the project name itself has multibyte - both of these cases are legal and no problems using them in other project types 2. clean and build 3. run it 4. application does not run - instead the output window and log shows the exceptions in the first attachment. 5. create another desktop project with dbase but not using multibyte at all in any path to the project or in project name. 6. the app runs ok and as expected. 7. expected behavior is that the db application will run. ken.frank@sun.com
removing incomplete keywd since provided additional info below. ken.frank@sun.com
I am sorry, I am not able to reproduce this issue because of issue 48902. Any clues how I can workaround it?
48902 is an old issue and is not valid anymore; we are able to use multibyte in project names or paths to run projects now so that should not be blocking you from replicating this - what is your environment and setup ? ken.frank@sun.com
Finally (after some struggle with Windows settings) I was able to overcome issue 48902 and reproduce this issue. Unfortunately it seems to be an issue of TopLink library. The same project works correctly when the directory is renamed not to contain multibyte characters. I tried to switch the persistence provider (used by the project) to Hibernate and it works correctly even with the multibyte characters in the name of directory. I don't know about any workaround for this issue => closing as WONTFIX.
*** Issue 120342 has been marked as a duplicate of this issue. ***
I sent mail to persistence alias about this; so far no comments. ken.frank@sun.com
issue has been filed in gf and its being looked at. but since fix wont be in gf that nb uses, can someone contribute some text for rel note ? ken.frank@sun.com
Corresponding GlassFish bug is https://glassfish.dev.java.net/issues/show_bug.cgi?id=3827
*** Issue 134164 has been marked as a duplicate of this issue. ***