Created attachment 59804 [details]
image

Created attachment 59805 [details]
exception

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.

ken.frank@sun.com

Pls look into this.

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.

ken.frank@sun.com

I was able to reproduce on Solaris 10 using build 0408.

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.

I don't think so.
Probably user will not be able to see properly some chars after changing encoding from his preferred value.

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.

ken.frank@sun.com

After discussion with Petr we agreed this is not showstopper for 61 release. Will be avaiable as a patch.

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.

ken.frank@sun.com

please provide fix in trunk soon since it needs to be verified there
before can be in the first 6.1 patch.

ken.frank@sun.com

sometnghi

nav064 - seems like your comment did not come thru - can you add it again ?

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

Nav,

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.

ken.frank@sun.com

Nav,
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
locale.

ken.frank@sun.com

Pls look into this.

http://hg.netbeans.org/main/rev/2d69ceeec38e

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

reopening

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 ?

Ken,

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.

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.

ken.frank@sun.com

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.

ken.frank@sun.com

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.

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.

changed target milestone.

The issue hasn't be fixed till 61patch1 nomination cut-off date.
Marked as release61_fixes_candidate2.

The fix was tested on Solaris ja_JP.UTF-8 locale.
Project encoding UTF-8 and eucJP. Also on WinXP with UTF-8.

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.

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.

http://hg.netbeans.org/main/rev/82a663784652

EUC_JP_SOLARIS locale is not a supported encoding. For all unsupported encodings, the wsdl will be generated in "UTF-8".

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.

ken.frank@sun.com

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.

ken.frank@sun.com

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.

http://hg.netbeans.org/main/rev/72a9bd6ed45d

Thanks. 

 

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.

ken.frank@sun.com

According to BP 1.0, WSDL supports either UTF-8 or UTF-16 only.
Setting default to "UTF-8".

http://hg.netbeans.org/main/rev/5c7b684a4eff

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.

ken.frank@sun.com

Ken,
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.
 

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.  

http://hg.netbeans.org/main/rev/ec61cba73d92

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.

Logging the exceptions at wsdl generation.

http://hg.netbeans.org/main/rev/d58a9d5f4338

QA, please verify this fix till 09-Jun-2008, so it can be part of NB 6.1 patch 2.

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.

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.

ken.frank@sun.com

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.

ken.frank@sun.com

Changing status to fixed. 

re-checked using 0604 build.
looks ok on S10 using ja_jp.pck

In ja locale also looks ok on Solaris 10.
wsdl from db was created properly without exceptions.

The fix has been ported into the release61_fixes repository.

http://hg.netbeans.org/release61_fixes/rev/85c28b8c77fb
http://hg.netbeans.org/release61_fixes/rev/5a4213f1e4eb
http://hg.netbeans.org/release61_fixes/rev/e90d5372ea08
http://hg.netbeans.org/release61_fixes/rev/449ce6334619
http://hg.netbeans.org/release61_fixes/rev/cb074d1bd427
http://hg.netbeans.org/release61_fixes/rev/2bd474014d96