Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 216526 - cannot compile web service client when generated on an italian machine
cannot compile web service client when generated on an italian machine
Status: VERIFIED FIXED
Product: webservices
Classification: Unclassified
Component: JAX-WS
7.2
PC Windows 7
: P2 with 1 vote (vote)
: 7.3
Assigned To: Denis Anisimov
issues@webservices
:
: 216492 219518 221092 222803 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-08 11:47 UTC by autozoom
Modified: 2013-07-10 08:57 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
IDE log (543.39 KB, text/plain)
2012-08-08 11:47 UTC, autozoom
Details

Note You need to log in before you can comment on or make changes to this bug.
Description autozoom 2012-08-08 11:47:29 UTC
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
Comment 1 autozoom 2012-08-08 11:47:41 UTC
Created attachment 122862 [details]
IDE log
Comment 2 sara_bz 2012-08-09 12:06:38 UTC
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)
Comment 3 autozoom 2012-08-09 15:22:34 UTC
you can work around this by setting the encoding to ISO-8859-1 for the project
(right-click/properties/sources/botton of the popup)
Comment 4 Lukas Jungmann 2012-09-01 08:54:44 UTC
can this be related? http://java.net/jira/browse/JAXB-915
Comment 5 Denis Anisimov 2012-09-03 06:59:50 UTC
There is a workaround so I lower the priority.
Comment 6 Denis Anisimov 2012-09-03 08:29:50 UTC
(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.
Comment 7 Denis Anisimov 2012-09-03 13:35:10 UTC
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.
Comment 8 Denis Anisimov 2012-09-03 13:45:45 UTC
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.
Comment 9 Denis Anisimov 2012-09-04 11:23:22 UTC
*** Bug 216492 has been marked as a duplicate of this bug. ***
Comment 10 autozoom 2012-09-04 12:35:18 UTC
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.
Comment 11 Denis Anisimov 2012-09-12 13:49:03 UTC
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.
Comment 12 David Konecny 2012-09-13 01:42:56 UTC
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.
Comment 13 autozoom 2012-09-18 07:13:19 UTC
yes, changing the encoding in one project modifies the queries.properties file and from then on all the new projects use that new encoding
Comment 14 Denis Anisimov 2012-10-04 14:58:00 UTC
*** Bug 219518 has been marked as a duplicate of this bug. ***
Comment 15 Denis Anisimov 2012-10-30 14:46:52 UTC
*** Bug 221092 has been marked as a duplicate of this bug. ***
Comment 16 muellermi 2012-10-30 16:44:32 UTC
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.
Comment 17 David Konecny 2012-10-30 21:40:51 UTC
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?
Comment 18 Denis Anisimov 2012-10-31 06:47:34 UTC
(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.
Comment 19 muellermi 2012-10-31 12:49:05 UTC
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?
Comment 20 Denis Anisimov 2012-10-31 13:40:56 UTC
(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).
Comment 21 Denis Anisimov 2012-10-31 13:43:45 UTC
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.
Comment 22 Denis Anisimov 2012-10-31 17:19:37 UTC
web-main#03b2ccac9c71
Comment 23 David Konecny 2012-11-01 00:18:58 UTC
The fix looks good Denis. Thanks.
Comment 24 Quality Engineering 2012-11-01 02:45:47 UTC
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
Comment 25 aeros 2012-11-29 16:29:05 UTC
We still have the problem with 'NetBeans IDE Dev (Build 201211280002)' with a machine who have french locale
Comment 26 Denis Anisimov 2012-11-29 17:34:06 UTC
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.
Comment 27 aeros 2012-12-03 08:42:54 UTC
(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...
Comment 28 Denis Anisimov 2012-12-06 09:43:23 UTC
(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.
Comment 29 Denis Anisimov 2012-12-06 13:06:00 UTC
web-main#3cf22a39da95
Comment 30 Quality Engineering 2012-12-07 02:44:20 UTC
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
Comment 31 aeros 2012-12-07 10:52:42 UTC
It works when i create new JavaFX project or Java Application.

Thanks.
Comment 32 markiewb 2013-03-25 21:28:15 UTC
*** Bug 222803 has been marked as a duplicate of this bug. ***
Comment 33 Abakhan 2013-07-10 08:57:12 UTC
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.


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