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.

Bug 132274 - I18N - wsdl from database, exception and incorrect wsdl file if in other locale on solaris
Summary: I18N - wsdl from database, exception and incorrect wsdl file if in other loca...
Alias: None
Product: soa
Classification: Unclassified
Component: SQL Project (show other bugs)
Version: 6.x
Hardware: Sun All
: P1 blocker (vote)
Assignee: nav064
Keywords: I18N, RELNOTE
Depends on:
Reported: 2008-04-08 02:10 UTC by Ken Frank
Modified: 2008-07-10 15:10 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

image (8.42 KB, image/gif)
2008-04-08 02:14 UTC, Ken Frank
exception (76.84 KB, text/plain)
2008-04-08 02:15 UTC, Ken Frank

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2008-04-08 02:10:31 UTC
what is correct categ and subcat of this ?
its seen when have sql project then new wsdl from db, but not sure its sql project ?

using pseudo localized nb, running in ja locale on solaris, not sure if happens on windows
or linux or mac

1. create sql project
2. new wsdl from db
3. get exception which will be attached about 
\303\327\314\277\305\252 [org.netbeans.modules.jdbcwizard.builder.wsdl.WSDLGenerator]: WSDLException:
faultCode=OTHER_ERROR: WSDLException:
faultCode=CONFIGURATION_ERROR: Unsupported Java encoding for writing wsdl file: 'EUC_JP_Solaris'.
WSDLException: faultCode=OTHER_ERROR: WSDLException: faultCode=CONFIGURATION_ERROR: Unsupported Java encoding for
writing wsdl file: 'EUC_JP_Solaris'.:

4. the wsdl file created is not correct - ie

source view is empty
wsdl and partner view has message - The WSDL is malformed.

see attached gif.
Comment 1 Ken Frank 2008-04-08 02:14:33 UTC
Created attachment 59804 [details]
Comment 2 Ken Frank 2008-04-08 02:15:07 UTC
Created attachment 59805 [details]
Comment 3 Ken Frank 2008-04-08 02:23:57 UTC
marked as p1 since means user cannot use this functionality at all in this case,
since running in en locale is not a valid workaround.
Comment 4 Venkat Srinivasan 2008-04-08 07:35:23 UTC
Pls look into this.
Comment 5 Ken Frank 2008-04-08 16:55:51 UTC
the problem does not happen if user is in the ja utf-8 locale on solaris,
only if in the ja locale (which is euc-jp encoding by default)
there is also a sjis ja locale on solaris.

For linux and perhaps mac, there is always the  legacy ja (euc-jp) locales
as well as the utf-8 ones, since users still do use the legacy encodings and locales.
Comment 6 kaa 2008-04-08 18:23:59 UTC
I was able to reproduce on Solaris 10 using build 0408.
Comment 7 Petr Blaha 2008-04-09 14:55:38 UTC
Does it mean that the workaround is set utf-8 locale? If yes, then the bug isn't p1 and it's P2 and should be documented
in release notes.
Comment 8 kaa 2008-04-09 15:08:44 UTC
I don't think so.
Probably user will not be able to see properly some chars after changing encoding from his preferred value.
Comment 9 Ken Frank 2008-04-09 15:34:19 UTC
I agree with kaa comments that its not really a workaround as is mentioned below; there is no utf-8 locale
on windows and also users should be able to run in legacy/other ja locales on
unix or mac.
Comment 10 Sergey Lunegov 2008-04-10 11:07:05 UTC
After discussion with Petr we agreed this is not showstopper for 61 release. Will be avaiable as a patch.
Comment 11 Ken Frank 2008-04-10 17:06:00 UTC
we need text for release note now since this an impact any user in other
locale and thus needed for en fcs/rc -  will you provide the text today  and workaround ?
sent it to me and I'll get it into relnotes.

workaround of running in utf-8 ja or other utf-8 locales can be mentioned
although its not really a good workaround for users who need or want to
run in legacy locales like ja euc-jp locale on solaris.
Comment 12 Ken Frank 2008-04-14 22:43:32 UTC
please provide fix in trunk soon since it needs to be verified there
before can be in the first 6.1 patch.
Comment 13 nav064 2008-04-15 09:31:48 UTC
Comment 14 Ken Frank 2008-04-15 15:39:34 UTC
nav064 - seems like your comment did not come thru - can you add it again ?

Comment 15 kaa 2008-04-16 00:25:31 UTC
This issue looks like a regression from 6.0.
There was issue 118769 - new wsdl from database not always work in other locales.
Probably it will help to fix it in 6.1 using the fix from 6.0
Comment 16 Ken Frank 2008-04-21 16:37:40 UTC

could this be fixed soon also like the others since it does block
users on that platform in other locale, even if they use english only
in project or file names.

fix can be in trunk first, then we verify, then to release61 for the patch -
we still have 3 more days to do it.
Comment 17 Ken Frank 2008-04-23 16:38:15 UTC
tomorrow is last day it can be fixed so can make it in the patch. Can it be done ?
this is not related to using a translated nb at all; it can impact any user in other
Comment 18 Venkat Srinivasan 2008-04-24 12:27:48 UTC
Pls look into this.
Comment 20 kaa 2008-04-24 17:36:26 UTC
verified: looks ok on WinXP (utf-8) and S10 (utf-8 and  euc-jp) Product Version: NetBeans IDE Dev (Build 20080424124045)
Wsdl doc was generated without exceptions. The only problem it has was described in the issue 132943
Comment 21 Ken Frank 2008-04-24 17:47:15 UTC

kaa, please read issue and other mail carefully.
this issue was about solaris, not about windows
thus invalid and incorrect to verify on windows
without verifying first on solaris.

and since fix of it was just few hours ago, are you sure in any 
case the build you were using has that fix ?
Comment 22 kaa 2008-04-24 18:04:47 UTC

I stated in my previous note I did verification on Solaris 10 (S10) using utf-8 and euc_jp encodings.
I am sure that build 20080424124045 had no exceptions for this. I think my verification was correct.
Comment 23 Ken Frank 2008-04-24 18:50:47 UTC
yes its my mistake here - I was looking at the other issue that had
incorrect copy/paste of bld # but put my comments here instead - and I apologize
for that.

as to the fix, I don't see if being fixed in latest trunk however
so will wait a few hours until next trunk and try again.

I'll take care of verifying it again or leaving reopen based on what 
I see in the next bld.
Comment 24 Ken Frank 2008-04-25 00:54:54 UTC
using a very recent trunk build 1722 or 23, it can't be verified;
same problems as in original reporting.

Andrey, what locale are you in when you run this; this issue
is not about project encoding but about encoding user is in
when they run nb.
Comment 25 Ken Frank 2008-04-25 02:11:18 UTC
on solaris ja_JP.PCK locale, its ok.

I don't know how your code queries for system locale and its possible
that even for ja locale, there might be different specific strings returned

how does the rest of nb do it ? isn't there a java specific way to do it
and not to parse for each locale ? (if that is what is happening)
I suggest asking others in nb teams whether soa/bpel teams or others -
how they do this same coding and perhaps clues with that.

Comment 26 Ken Frank 2008-04-25 02:12:24 UTC
same problems happens if in solaris zh locale (zh_CN)

has the fix really been tested in solaris zh locale, ja locale
and other non utf8 ja and zh_CN locales ?
though it might be more general problem in not recognizing a larger
number of locale names.
Comment 27 Sergey Lunegov 2008-04-25 07:45:32 UTC
changed target milestone.
Comment 28 pgebauer 2008-04-25 08:24:48 UTC
The issue hasn't be fixed till 61patch1 nomination cut-off date.
Marked as release61_fixes_candidate2.
Comment 29 kaa 2008-04-25 12:54:43 UTC
The fix was tested on Solaris ja_JP.UTF-8 locale.
Project encoding UTF-8 and eucJP. Also on WinXP with UTF-8.
Comment 30 kaa 2008-04-28 13:53:10 UTC
I agree with reopening. The issue doesn't exist in ja UTF-8 so my verification was incorrect.
I missed this point. My apologies for all who was affected by this.
Comment 31 kaa 2008-04-29 15:10:22 UTC
Hi Nav,

I verified it in ja utf-8 only, where the issue doesn't exist. Later I found additional comment on this (see above, Tue
Apr 8 15:55:51) where stated that the issue does not happen if user is in the ja utf-8 locale on Solaris.
Comment 32 nav064 2008-04-29 17:18:50 UTC

EUC_JP_SOLARIS locale is not a supported encoding. For all unsupported encodings, the wsdl will be generated in "UTF-8".
Comment 33 Ken Frank 2008-04-29 20:12:18 UTC
am reopening - please resolve again if I am mistaken here.

I don't think you can force the file into utf-8
if the encoding of the project the user is in
is a different encoding. that is basic nb functionality.

and also, this error happens just because user is running in a non utf8 ja locale,
but they are allowed to do this - and in other ja solaris locale like ja_JP.PCK
it did not happen, at least according to your comments in other mail.

also, EUC_JP_SOLARIS result might be based
on some not correct way the code is reading or parsing
or perhaps not correct api is being used -
this does not happen for any other module;
user can be in any locale and use any project encoding

please clarify and fix this if the current fix will not handle situations mentioned above.
Comment 34 Ken Frank 2008-04-29 21:23:45 UTC
what I mean by "force the file into utf-8 encoding" is that if
user is running nb in project with different encoding, then having
this file be in utf-8 encoding won't be what is needed and thus
data wont be read/written ok.
Comment 35 nav064 2008-05-02 11:50:02 UTC
Partial check-in. Verfied in windows locale. But, testing this in solaris japanese doesn't seem to work. Need some help
in trying this out on other systems/locales to sort out if this is an issue with Solaris.


Comment 36 Ken Frank 2008-05-02 17:57:16 UTC
I dont think the problem was in windows, did you see original problem there ?
It was reported on solaris and original fix did not work on solaris
thus as you mention if it does not work still running in solaris
ja locale, then the issue is not really fixed.
Comment 37 nav064 2008-05-08 09:32:39 UTC
According to BP 1.0, WSDL supports either UTF-8 or UTF-16 only.
Setting default to "UTF-8".
Comment 38 Ken Frank 2008-05-08 16:10:16 UTC
reopening since info provided is not clear and since its need to be known - what is the user experience using all solaris ja
locales ?  What are the restrictions ? Does it mean user cannot run in solaris ja
locale (vs utf-8 ja or pck ja solaris locales) or they will see the exception ?

And if so, why is it possible for users to run all other parts of netbeans ok in solaris
ja locale but can't use this functionality ? And is that acceptable restriction for users ?

Please make sure to actually run in all 3 solaris ja locales
and provide complete information - we have not seen an issue like this before that needed
to reopened so many times.
Comment 39 nav064 2008-05-09 07:25:13 UTC
The issue is with just the xml encoding used in wsdl. WSDLWriter is not able to map UTF-8 to the locale encoding(say ja)
in which it fails to write wsdl. For all such locales, the change made, writes a wsdl, which uses UTF-8 encoding. If
this still doesn't completely explain, let's take this offline.
I agree with you on this boomerang issue.
Comment 40 nav064 2008-05-09 07:59:30 UTC
Tested on all the 3 japanese locales and it's working fine. As fas a user experience is concerned, it is not a
limitation, it's a must as it has to be in UTF-8. As we can see, the file is written fine, except for 132943, which
again I think is a problem with WSDL editor, in displaying the characters.  
Comment 41 nav064 2008-05-22 14:25:10 UTC

This change is required in sql.project - which is same as the change done in the sql.wizard - for the fix to be complete.

Resolving further issues.
Comment 42 nav064 2008-05-28 07:27:51 UTC
Logging the exceptions at wsdl generation.
Comment 43 pslechta 2008-05-28 14:11:04 UTC
QA, please verify this fix till 09-Jun-2008, so it can be part of NB 6.1 patch 2.
Comment 44 kaa 2008-05-29 17:44:09 UTC
checked with trunk build 0529 in the following locales (Solaris 10):
ja_JP.PCK, ja_JP.UTF-8, ja

wsdl from database was generated without exceptions.
Source, design and partner views look ok.
Comment 45 Ken Frank 2008-06-01 16:56:07 UTC
qe engineer has verified it but its still in the reopened state, and developer
who fixed it needs to put it in resolved state first, so we are all clear on it.

Nav, please either put in resolved state or clarify that its not all fixed yet.

until it can be in resolved state, it can't be put in verified state, and that
means it can't get into the patch.
Comment 46 Ken Frank 2008-06-03 20:59:45 UTC
moving to p1; developer has not put in resolved state so we can't know 
for sure if resolved, which means we can't verify it in iz, which means
it can't be in patch 2, and the deadline for it is close.
Comment 47 nav064 2008-06-04 06:42:51 UTC
Changing status to fixed. 
Comment 48 kaa 2008-06-04 16:18:49 UTC
re-checked using 0604 build.
looks ok on S10 using ja_jp.pck
Comment 49 kaa 2008-06-04 16:23:42 UTC
In ja locale also looks ok on Solaris 10.
wsdl from db was created properly without exceptions.