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]
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?
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.
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
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.
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.
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.
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.
could you raise prio of the runtime openesb issue and let them know its critical fix we need
for nb6.1 ?
Thanks - Ken
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