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.
Summary: | I18N - wsdl from database, exception and incorrect wsdl file if in other locale on solaris | ||
---|---|---|---|
Product: | soa | Reporter: | Ken Frank <kfrank> |
Component: | SQL Project | Assignee: | nav064 <nav064> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | blaha, jf4jbug, kaa, narayanaa, sustaining |
Priority: | P1 | Keywords: | I18N, RELNOTE |
Version: | 6.x | ||
Hardware: | Sun | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
image
exception |
Description
Ken Frank
2008-04-08 02:10:31 UTC
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. 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 |