Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #134728 +++ I opened this defect as a clone of #132728 because I don't have the permission to reopen. Please see the contents of #134728 for detail about this problem. This defect is opened as a defect in version 1.5 since the product that I'm testing uses WTP 1.5, but the same problem happens in WTP v2.0. The reporter of #134728 had reported a defect AXIS-2459 on Apache JIRA, then that eclipse defect had been closed. However I reopened this defect based on the comment from developer of the product. ----- comment from our product developer ----- The problem is in RAD/WTP, and the fact that AXIS does not rush to add the option to restore old behavior is not the reason to not fix it, or blame on AXIS. I do not think it is necessary to change AXIS. Invoker of WSDL2Java (which is WTP) should know its features - that AXIS version will emit Java in UTF-8 encoding. The same code that invokes WSDL2Java should inform rest of Eclipse tools of that encoding by setting the encoding on the container where Java will be emitted. WTP should make use of org.eclipse.core.resources.IContainer.setDefaultCharset(String charset, IProgressMonitor monitor) API, when invoking non Eclipse tool. -------------------------------------- So, I would like to ask you to fix the problem using the method described in above. Thanks.
Kelvin, could you please do some investigation on this problem?
Ishii-san, I think I understand the problem but would need your confirmation because I don't have a Japanese machine to verify. I was able to reproduce a similar problem on my English Windows machine where the default encoding is "Cp1252". Under this encoding, the Java files have corrupted contents. Using the IContainer.setDefaultCharSet API call is equivalent of doing a right-click -> properties -> Resource -> set the Text file Encoding to "UTF-8". If we are doing this, we might be setting the encoding for the "src" folder. Do you see any potential problems? Regards, Kelvin
Hello Kelvin, Thanks for your prompt reply. I think the potential problem is that an encoding mismatch might happen if WTP generates Web Service Java source in an existing Project that has Java source code already. If existing source code is not written in UTF-8, changing src folder's encoding might affect these existing source code. If it is possible to change property of each generated file, it is better. Thanks.
Created attachment 79303 [details] Patch for setting charset for generated Java files This patch set the charset for all Axis generated files to UTF-8.
Patch reviewed and tested. Thanks Kelvin! I've committed and released the change to HEAD as v200710302058. It will be in the WTP 3.0 build.
Please verify the defect you originated with a recent WTP driver which could be found in: http://download.eclipse.org/webtools/downloads/ If defects in resolved state is not verified within a couple of weeks, the development team might verify and close the defect on the originator's behalf. Thank you for your attention!
mass change to add 'contributed' keyword based on bugzilla query, please correct if that's not accurate (by marking patches as obsolete and removing the 'contributed' keyword.
verified using IES3.4_RC3 + wtp3.0_RC3_20080604. Thanks!
Closing defects in verify states.