Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 151036 - I18N - js stub generator doesn't honor project wide encoding
I18N - js stub generator doesn't honor project wide encoding
Status: VERIFIED FIXED
Product: webservices
Classification: Unclassified
Component: REST
6.x
All Windows Vista
: P3 (vote)
: 6.x
Assigned To: Lukas Jungmann
issues@webservices
65fixes1-verified
: I18N
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-22 16:33 UTC by Lukas Jungmann
Modified: 2009-02-19 23:29 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
editor's screenshot (83.14 KB, image/png)
2008-10-22 16:39 UTC, Lukas Jungmann
Details
proposed patch (7.18 KB, text/plain)
2008-10-22 18:19 UTC, Lukas Jungmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lukas Jungmann 2008-10-22 16:33:11 UTC
-create a web project (ie. WA1)
-set it to use windows-1252 character encoding in project properties -> sources
-create an enity class named "Myóc" (ó is 00F3 in unicode) there
-create a rest service from this class

-create another web project (ie. WA2)
-set it to use windows-1252 character encoding in project properties -> sources
-create REST js stub (new file -> web services -> restful ws client stubs) for WA1 project
   (in the last panel of the wizard press Add Project button, look up WA1 project, keep defaults for the rest of fields
in the wizard and finish it)

-open web-pages -> rest -> wa1 -> Myóc.js file in the IDE's editor (or in some other (ie win notepad) which can show
file in hex mode)

=> Myóc.js is written using UTF-8 encoding (on the ó's position one can find 00C3 00B3 characters in hex), I'd expect it
to be in windows-1252 encoding since that's the one I set for the project
Comment 1 Lukas Jungmann 2008-10-22 16:39:53 UTC
Created attachment 72481 [details]
editor's screenshot
Comment 2 Ken Frank 2008-10-22 17:38:53 UTC
It might be that since project encoding was changed, that there could be some assumptions
or charset tags in files created before the project encoding was changed, that might cause this - 
am just guessing here.

I realize it could just be that creation of .js does not use project encoding/feq but

it could be good to make sure the steps are done to avoid having the original encoding value of the project
be noted somewhere even if project encoding prop is changed - thus suggest the following steps:

1. create some java project, it will use default utf-8 encoding; change this project encoding prop to the 1252

2. then create the first and subsequent web projects - they will be created in 1252 from the beginning
and see if problem still happens.

ken.frank@sun.com
Comment 3 Lukas Jungmann 2008-10-22 18:19:19 UTC
thanks for your comment, Ken. Problem here is that the code responsible for .js files creation uses new
OutputStreamWriter(projectStub.getOutputStream(lock), "UTF-8"); which means that UTF-8 will be always used regardless of
what's set for the project (and looking more through the code I see no use of FileEncodingQuery to get correct encoding
when it's needed), so to answer your question - yes, problem will persist even if the project will be created with
win-1252 encoding from the beginning.

I'm attaching a patch which should fix this issue in trunk ;-) Feel free to use it or let me know and I can push it to main
Comment 4 Lukas Jungmann 2008-10-22 18:19:48 UTC
Created attachment 72487 [details]
proposed patch
Comment 5 Ken Frank 2008-10-22 18:29:11 UTC
jungi, thanks for the explanation; can you please push it to trunk and we'll verify
it as we begin testing for next nb release or for first patch - perhaps this one could go into patch ?

kaa, was this problem seen by you when you were testing web services ?

ken.frank@sun.com
Comment 6 Lukas Jungmann 2008-10-22 18:44:26 UTC
ok, I'll take care of this
Comment 7 Lukas Jungmann 2008-10-22 18:52:26 UTC
fixed locally in 06a5b9d41094, I'll push this later today.

Added 65fixes1-candidate sw as well since I still remember hard times I had with proper file encodings as a usual user
in webapps back in NB 3.5 & 3.6 times.

Ayub, review my patch please.

Thanks.
Comment 8 Ayub Khan 2008-10-22 19:10:31 UTC
Excellent work Lukas!

The fix 06a5b9d41094 looks good.

-Ayub
Comment 9 Quality Engineering 2008-10-23 04:50:29 UTC
Integrated into 'main-golden', will be available in build *200810230201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/06a5b9d41094
User: Lukas Jungmann <jungi@netbeans.org>
Log: IZ #151036: I18N - js stub generator doesn't honor project wide encoding
Comment 10 kaa 2008-10-28 18:01:30 UTC
verified:

Product Version: NetBeans IDE Dev (Build 200810280201)
Java: 1.6.0_06; Java HotSpot(TM) Client VM 10.0-b22
System: Windows XP version 5.1 running on x86; MS932; ja_JP (nb)

re-checked with build 1005, WinXP, Japanese locale:
The issue didn't happen with utf-8 project encoding.
The issue was reproducible for win-31j project encoding.

Also reproducible with NetBeans IDE 6.5 RC2 (Build 200810231029)

Comment 11 pgebauer 2008-11-10 15:09:46 UTC
Since this issue is P3 priority, in accord with rules "How to include issues into patch"
(http://wiki.netbeans.org/NetBeansPatches) it must include an explanation as to why its backport is necessary and how
safe it is.

Could you please provide such explanation?
Comment 12 Lukas Jungmann 2008-11-18 15:20:09 UTC
justification:
 in case project uses non-default encoding some (js) IDE generated files will be generated using UTF-8 encoding which
may cause troubles for users who will develop (localized) application using ie some chinese encoding. The only
workaround for this is to find some other app/editor which is able to convert files from UTF-8 to user defined encoding

how safe:
 fix replaces hardcoded "UTF-8" argument used in OutputStreamWriter with call to IDE wide FileEncodingQuery which is
guaranteed to return valid, non-null value
Comment 13 pslechta 2008-11-19 10:17:40 UTC
The fix has been backported into release65_fixes repository.

http://hg.netbeans.org/release65_fixes/rev/f57544705836


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo