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 1109, ja_JP 1. Create CompApp using using eng chars in its name and location. 2. Create Bpel Module using mbyte only for its name 3. Add this module to the app 4. Deploy the app There is an error in output window and deployment failed. See attached file.
Created attachment 52938 [details] image
Also JBI Modules with mbyte in their names are shown with underscores. What is the background/reason for replacing the mbyte in names with underscores?
Some investigations: a. if compapp project has mbyte name but bpel does not, it is ok. b. if bpel and compapp project has en project names, but path to project has mbyte, things are ok. c. See also issue 112326
can at least this be analyzed/debugged now in case the fix can come into nb6 ? this situation means that users cannot use non ascii in names of other soa projects like bpel or xslt or other projects that would become added to compapp project as jbi modules (a list of those types will be helpful) something changed some weeks ago in how the added jbi module was named as it went into the compapp as a jar as to using underscore ( __ ) characters instead of original multibyte characters in its name and it seems from errors that something is assuming or looking for the name of somethings using actual multibyte but seeing only the underscore characters. before that underscore change, it was ok. I can't be more exact in these comments since don't know the flow of what happens when module is added to compapp. also see in the config files of such a project the files like jbi.xml, application.xml and others - in the editor, some parts of the files show the mbyte ok, some not ok and sometimes as underscores (where the original mbyte was) so it could also be some encoding handling situation happening also. ken.frank@sun.com
added RELNOTE keyword; it seems important for this to be release noted if can't be fixed since it means users cannot use non ascii (or perhaps just non multibyte) in names of any modules that goes into the compapp. ken.frank@sun.com
Vitaly, please evaluate.
Output window has two lines with ERRORs. (see attached image above) They have underscore instead of correct mbyte. Described problem is not just a runtime one but happens during building part.
Added this issue to RC2 and FCS Release Notes.
Can this be fixed for sierra/nb6.0.1 ? I feel that this is extremely important issue for i18n. please let us know if keyword can be added to get it on track for fixing for sierra or if it needs to be at p1 - I do feel its p1 kind of importance, esepecially since the functionality had worked in the past in nb6. ken.frank@sun.com
as per sustaining process, I added release60_fixes_candidate2 status whiteboard entry to this issue, since feel it does need to be fixed for patch 2 (patch 1 is already closed). Can someone on team evaluate this ? Please contact me for info on details of the process as to what alias or process to use to notify about fixes and integrations. Also let me know if needs to be at P1. ken.frank@sun.com
Will fix in 6.0.1.
thanks for planning to fix for 6.0.1 timeframe it seems that fix is needed in trunk first and verified before going into patch 2 -- please let us know when fix is in trunk and we will test it then. ken.frank@sun.com
The problems in the design time have been fixed. However, there is still a runtime issue that prevents successful deployment. I filed https://open-esb.dev.java.net/issues/show_bug.cgi?id=159 I guess NB 6.0.1 will bundle with the same runtime as NB 6.0. If that's the case, we have to drop this from 6.0.1. Otherwise, feel free to increase the priority of the runtime ticket.
Drop this from 6.0.1 because of the runtime issue.
Jun, could you raise prio of the runtime openesb issue and let them know its critical fix we need for nb6.1 ? Thanks - Ken ken.frank@sun.com
Raised the priority of the runtime issue from P3 to P2.
The problem in the runtime (https://open-esb.dev.java.net/issues/show_bug.cgi?id=159) has been fixed. Please verify.
build 0311, RH