Bug 121834

Summary: I18N - CompApp containing a module with mbyte name couldn't be deployed
Product: soa Reporter: kaa <kaa>
Component: Composite ApplicationAssignee: Jun Qian <jqian>
Status: VERIFIED FIXED QA Contact: issues <issues.netbeans.org>
Priority: P2 CC: kfrank, tli
Version: 6.xKeywords: I18N, RELNOTE
Target Milestone: -S1S-   
Hardware: All   
OS: All   
Whiteboard:
Issue Type: DEFECT Exception Report:
Attachments: image

Description kaa 2007-11-13 16:02:40 UTC
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.
Comment 1 kaa 2007-11-13 16:03:11 UTC
Created attachment 52938 [details]
image
Comment 2 kaa 2007-11-13 16:14:41 UTC
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?
Comment 3 kaa 2007-11-13 16:17:51 UTC
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
Comment 4 Ken Frank 2007-11-14 15:35:55 UTC
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
Comment 5 Ken Frank 2007-11-14 15:38:33 UTC
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
Comment 6 Sergey Lunegov 2007-11-14 16:51:11 UTC
Vitaly, please evaluate.
Comment 7 kaa 2007-11-14 18:38:53 UTC
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.
Comment 8 Irina Filippova 2007-11-20 05:07:04 UTC
Added this issue to RC2 and FCS Release Notes.
Comment 9 Ken Frank 2007-11-22 18:48:09 UTC
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
Comment 10 Ken Frank 2007-12-03 16:03:03 UTC
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

Comment 11 Jun Qian 2007-12-04 01:13:48 UTC
Will fix in 6.0.1.
Comment 12 Ken Frank 2007-12-13 17:51:01 UTC
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
Comment 13 Jun Qian 2007-12-18 21:45:38 UTC
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.
Comment 14 Jun Qian 2008-01-08 18:43:26 UTC
Drop this from 6.0.1 because of the runtime issue.
Comment 15 Ken Frank 2008-01-08 18:52:43 UTC
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
Comment 16 Jun Qian 2008-01-08 19:25:09 UTC
Raised the priority of the runtime issue from P3 to P2.
Comment 17 Jun Qian 2008-03-07 19:37:57 UTC
The problem in the runtime (https://open-esb.dev.java.net/issues/show_bug.cgi?id=159) has been fixed. Please verify.
Comment 18 kaa 2008-03-17 18:35:59 UTC
build 0311, RH
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo