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.
build 1112 RC1, ja_JP 1. Create Enterprise Application using mbyte in its name. 2. Run the app There is an error while running the app. Seems r/w problem. See attached image
Created attachment 52996 [details] image
Evven if the names of the ejb/war/app client do not have mbyte at the end of their names the same problem happens.
Created attachment 52997 [details] mbyte only at the begining
Created attachment 52998 [details] GF log
Andrey, if mbyte is in name of ent app, but not in name of the appclient,ejb, webapps projects as created in the wizard, does the problem still happen ? To dev, I don't if this is related at all: when building it, it mentions the names of the jar and war files with underscore instead of actual multibyte used ie Warning: __Jot___Jot_EnterpriseApplication7__-app-client.jar modified in the future. Warning: __Jot___Jot_EnterpriseApplication7__-ejb.jar modified in the future. Warning: __Jot___Jot_EnterpriseApplication7__-war.war modified in the future. also to note, bug filer has installed nb when in that ja locale, which means gf was installed when also from that locale. ken.frank@sun.com
the answer is No: if mbyte is in the name of EntApp only, I was able to run it.
adding RELNOTE keyword since if can't be fixed, it will be important to communicate that non ascii cannot be used in names of ejb, web and appclient for enterprise app projects. ken.frank@sun.com
work-around: turn off directory deployment it looks like this is https://glassfish.dev.java.net/issues/show_bug.cgi?id=3456 manifested inside NetBeans.
can team see if it can be fixed for an upcoming patch or 6.0.1 ? we allow users to use non ascii in names of projects and paths and fixing this would be consistent with that; I don't know if it depends on the referred to gf issue though ? that one does not seem to be i18n related - maybe its really about the underscores vs the mbyte ? (though we substitute the mbyte with the underscores for the uri) ken.frank@sun.com
added release60_fixes_candidate2 to status whiteboard since that is process from sustaining to see if this can be fixed for patch 2. Can team see if its a fix that can be done for that patch ? I can point team to info on the alias and internal sustaining process about it. ken.frank@sun.com
please attach an ear file that demonstrates this issue.
Here is the testing that I have been able to do... create an ent app that: has a name that starts with MB chars: dir deploy fails, archive deploy successful has a name that ends with MB chars : dir deploy successful, archive deploy successful has a name with interior MB chars : dir deploy successful, archive deploy successful has only MB chars in its name : dir deploy fails, archive deploy successful At first glance, it seems like we should disable directory deployment when the ent app has MB characters in its name. So, how do I tell that a String has MB chars in it?
Created attachment 53838 [details] project
I found out that for patch2, that fix needs to be in trunk first, then verified, thus please let us know when fix is there and we'll get it verified immediately. ken.frank@sun.com
http://deadlock.netbeans.org/fisheye/changelog/netbeans/serverplugins/sun?cs=MAIN:vkraemer:20071217190219
reproducible: Product Version: NetBeans IDE 6.0 (Build 200712200000) Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b05 System: Windows XP version 5.1 running on x86; MS932; ja_JP (nb) http://smetiste.czech.sun.com/builds/netbeans/6.0.1/daily/latest/
Please attach the server log, ide message log and ant output.
Created attachment 54418 [details] ant log
Created attachment 54419 [details] gf log
Created attachment 54420 [details] ide log
I think you need to check against a trunk build... not the 6.0.1 build... which is not the trunk... I think this is the front-door to the bits you need to check... http://bits.netbeans.org/dev/nightly/latest/ Please reopen if this is still an issue in the build from this location.
using 1220 build from http://bits.netbeans.org/dev/nightly/ deployment looks ok.
The fix has been ported into the release601_fixes branch. Checking in DirectoryDeploymentFacade.java; /cvs/serverplugins/sun/appsrv81/src/org/netbeans/modules/j2ee/sun/ide/j2ee/incrdeploy/Attic/DirectoryDeploymentFacade.java,v <-- DirectoryDeploymentFacade.java new revision: 1.12.10.1; previous revision: 1.12 done