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.
When you generate web service clients on an italian version of Windows7, you get comments like * Recupera il valore della propriet? data in the generated sources, and this prevents the compiler from compiling it: error: unmappable character for encoding UTF-8 and you cannot even open it in the editor example of generated code: /** * Recupera il valore della propriet� dataAppuntamento. * * @return * possible object is * {@link XMLGregorianCalendar } * */ public XMLGregorianCalendar getDataAppuntamento() { return dataAppuntamento; } Product Version = NetBeans IDE 7.2 (Build 201207171143) Operating System = Windows 7 version 6.1 running on amd64 Java; VM; Vendor = 1.7.0 Runtime = Java HotSpot(TM) 64-Bit Server VM 21.0-b17
Created attachment 122862 [details] IDE log
same problem here, but on a Mac OS X machine with Java6 installed. With previous versions of Netbeans this bug is not present. Product Version: NetBeans IDE 7.2 (Build 201207171143) Java: 1.6.0_33; Java HotSpot(TM) 64-Bit Server VM 20.8-b03-424 System: Mac OS X version 10.7.4 running on x86_64; MacRoman; it_IT (nb)
you can work around this by setting the encoding to ISO-8859-1 for the project (right-click/properties/sources/botton of the popup)
can this be related? http://java.net/jira/browse/JAXB-915
There is a workaround so I lower the priority.
(In reply to comment #4) > can this be related? http://java.net/jira/browse/JAXB-915 It's not the same issue but it is really similar. Thank for the point. The issue is in the JAXB xjc task. It has wrong localization messages for IT locale. So it is IT locale specific and this is not NB issue. Classpath for "wsimport" ant task which used to generate service client is taken from target JEE server. I suppose your target server is GF with JAXB version >=2.2.5 Starting from the latter version JAXB has localized messages and the issue: http://java.net/jira/browse/JAXB-916.
It turns out that xjc produces encoding specific Java source code. So the resulting code is not UTF-8 based but depends on encoding (if it is set or system by default). The issue is consequence of different encodings used for wsimport task source generation (system default) and project source encoding.
So the issue is NB issue actually but I have to find its reason. In my case NB started with "it_IT Cp1252" locale force the project to use cp1252 locale for source. This encoding is also used by java compiler. So the encodings are synchronized and all works fine. So please provide information about your case : what encoding is used in your project which you use to create WS client ? As I understand it is UTF-8, right ? The next question is : did you explicitly set this encoding or it is default setting ? If you didn't change the encoding then it is project properties bug I suppose: encoding in the project should be set to the system encoding. Otherwise this is not a bug but looks like bad user workflow. It is possible to fix the issue on the WS side using encoding attribute of wsimport task but there is a issue with various versions: there is no such attribute in the versions below 2.2.5. So I can't just introduce the "encoding" attribute for wsimport task.
*** Bug 216492 has been marked as a duplicate of this bug. ***
Yes UTF-8 is the default I get when creating a new project. I need to switch to ISO-8859-1 to be able to build it.
So the source of the issue is difference between system encoding and Web project default encoding settings. I'm not sure is it general Project issue or just a Web Project specific. But the project encoding should be default system encoding.
NetBeans remembers the last encoding used and use it for all newly created projects. The first project you ever created in the IDE with fresh userdir (J2SE, J2EE or PHP or any other type) will get "UTF-8" encoding. If you open project properties and change it to for example Win1250 then that will become a new default and will be used automatically by all newly created projects onwards. That's how it's been implemented for very long time and there were no changes I'm aware of recently. Could you verify please that setting some encoding in one of your projects and creating a new project will result in this newly picked encoding being used automatically? The last used encoding is stored in <your-userdir>/config/Preferences/org/netbeans/modules/queries.properties file as default-encoding property. Thanks.
yes, changing the encoding in one project modifies the queries.properties file and from then on all the new projects use that new encoding
*** Bug 219518 has been marked as a duplicate of this bug. ***
*** Bug 221092 has been marked as a duplicate of this bug. ***
I faced this problem today, and it had been marked as duplicate of this closed bug. But this bug is still existent, thus I re-opened it. Setting to incomplete will not solve the problem. Setting the encoding of the project will not solve the problem too. The system has to work correctly even though it is set to UTF-8, which is the ***standard*** encoding for xml files.
Denis, if I got it right the problem is that project specific encoding is not passed on some command line tool(s). And consequently the command line tool uses OS default encoding and these files later are causing conflicts as IDE expects project specific encoding. Should not the fix be as easy as to instruct the command line to user project specific encoding?
(In reply to comment #17) > Denis, if I got it right the problem is that project specific encoding is not > passed on some command line tool(s). And consequently the command line tool > uses OS default encoding and these files later are causing conflicts as IDE > expects project specific encoding. Yes. >Should not the fix be as easy as to instruct > the command line to user project specific encoding? No. I don't see how to fix it in a good way on the WS side. Only new version of xjc ( or wsimport, wsgen ) has "encoding" attribute. Build file modification to add this attribute will work only for recent GF version and won't work for any older. So this is not a fix. It could be fixed by forcing system default encoding for sources instead of UTF-8. At the moment we have inconsistency between system default encoding, which is used by overall IDE (along with ant) and sources encoding which is UTF-8 by default. It causes the issue and probably will cause issues in the future (any ant task which uses system default encoding is a source of the issue). I would suggest to use the same encoding across all IDE. The other simple solution could be uses sources encoding property as a system default encoding for ANT infrastructure. But I don't know if it is possible.
why is xjc of the app server used? as a workarround, can't you use the one from jdk? or just let the user choose?
(In reply to comment #19) > why is xjc of the app server used? > as a workarround, can't you use the one from jdk? > or just let the user choose? XJC is not used directly. wsimport ant task uses it internally. Target server wsimport task is used because it confirms to the runtime environment. It allows to use most recent version of WS functionality (in case latest JEE target server).
OK, I see how the issue could be fixed on WS side. I would still prefer to solve it in some generic way (f.e. run any ant task with specified system default encoding). But I think it is impossible to agree about it.
web-main#03b2ccac9c71
The fix looks good Denis. Thanks.
Integrated into 'main-golden', will be available in build *201211010001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/03b2ccac9c71 User: Denis Anisimov <ads@netbeans.org> Log: Fix for BZ#216526 - cannot compile web service client when generated on an italian machine
We still have the problem with 'NetBeans IDE Dev (Build 201211280002)' with a machine who have french locale
Please provide exact steps to reproduce. What target J2EE server do you use ? How do you check the issue : on existing project or on the new one (created from scratch) ? Only new involvement of XJC task should works correctly ( like newly created WS or WS client ). All previously created entities are still affected because the fix is inside ant target defenition. All previously created ant targets are not regenerated and still contain the issue even with new binaries.
(In reply to comment #26) > Please provide exact steps to reproduce. > > What target J2EE server do you use ? > How do you check the issue : on existing project or on the new one > (created from scratch) ? > Only new involvement of XJC task should works correctly ( like newly created WS > or WS client ). All previously created entities are still affected because > the fix is inside ant target defenition. All previously created ant targets are > not regenerated and still contain the issue even with new binaries. We use Java 7u9 and Jboss AS 7.1.1 Final. I have used projects who was created with NetBeans 7.1.2. Then now with your explanations i created new Java project and added new webservice client but the error still the same...
(In reply to comment #27) > (In reply to comment #26) > > Please provide exact steps to reproduce. > > > > What target J2EE server do you use ? > > How do you check the issue : on existing project or on the new one > > (created from scratch) ? > > Only new involvement of XJC task should works correctly ( like newly created WS > > or WS client ). All previously created entities are still affected because > > the fix is inside ant target defenition. All previously created ant targets are > > not regenerated and still contain the issue even with new binaries. > > We use Java 7u9 and Jboss AS 7.1.1 Final. > I have used projects who was created with NetBeans 7.1.2. > Then now with your explanations i created new Java project and added new > webservice client but the error still the same... So where is the requested exact steps to reproduce ? You'd mentioned here Jboss AS 7.1.1 (which is not supported by NB !) and "new Java project". What information is relative to the issue is what is not ? It is very hard to identify the issue from such descriptions. I've identified the exact issue only after spending some time to search all possible cases based on your poor comment. It seems that plain J2SE project where you are trying to create the WS client is your case. Jboss AS has no any relation to the issue at all. The issue is fixed for J2EE projects. And it is really still valid for J2SE. The difference in the project types is key information in this issue.
web-main#3cf22a39da95
Integrated into 'main-golden', will be available in build *201212070001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/3cf22a39da95 User: Denis Anisimov <ads@netbeans.org> Log: Fix for BZ#216526 - cannot compile web service client when generated on an italian machine
It works when i create new JavaFX project or Java Application. Thanks.
*** Bug 222803 has been marked as a duplicate of this bug. ***
I had the same issue with 7.2 and also after changing to 7.3.1 on a french installation. Solved with a change in the 'netbeans.conf' file in the netbeans installation folder under '\etc' : Add « -J-Dfile.encoding=UTF-8"» to the line : «netbeans_default_options="[…]"» so you get «netbeans_default_options="[…] -J-Dfile.encoding=UTF-8"». Restart netbeans.