[JBoss JIRA] (JBWS-3957) publishWsdlImports writes WSDL-XML files with wrong characterset under Windows
9:42 a.m.
[
https://issues.jboss.org/browse/JBWS-3957?page=com.atlassian.jira.plugin....
]
Martin Both commented on JBWS-3957:
-----------------------------------
Hello Jim Ma,
it is not my code. It is the code of JBoss application server witch write and read WSDL
files during a deployment of a webservice if there is no explicit wsdlLocation in the war
file.
1. I have a WSDL file in UTF-8 encoding. Both file encoding and XML-encoding are UTF-8.
2. I have generate Java code with JAX-WS and write my service implementation.
3. I create a deployment archive. A war file without the original wsdl file but it is
based on the original wsdl file.
4. I deploy my war on JBoss (or WildFly it's the same error). JBoss generate a new
WSDL file in the data directory and read also this generated files a second later. That is
stupid but that it is. If the JBoss Java VM is configured to use the file.encoding Cp1252
than JBoss wirte imported WSDL files in that encoding but says in the XML-Prolog that the
encoding is UTF-8 but it is'nt.
JBoss reads the corrupt WSDL and complain that the file is wrong. How stupid! The
deployment ends with an error.
I'm using a selfmade fix of WSDL4J. I try to open a ticket against WSDL4J but it is
not possible. Maybe WSDL4J is to old or the guys of WSDL4J like there own mistakes so
much. I don't know.
It is also possible to fix that error in JBoss if JBoss would write WSDL import files
always in UTF-8 encoding. Or better don't write and read because it is useless and
would be faster without.
My fix to WSDL4J is to remove the default mapping because than WSDL4J would throw errors
in case of missing mapping. Much importend is the new mapping between Cp1252 and
Wndows-1252..
//xmlEncodingMap.put(System.getProperty("file.encoding"),
// Constants.XML_DECL_DEFAULT);
xmlEncodingMap.put("Cp1252", "Windows-1252");
Martin
publishWsdlImports writes WSDL-XML files with wrong characterset
under Windows
------------------------------------------------------------------------------
Key: JBWS-3957
URL: https://issues.jboss.org/browse/JBWS-3957
Project: JBoss Web Services
Issue Type: Bug
Environment: WildFly 9, Windows 7 with default Java file.encoding Cp1252.
Reporter: Martin Both
Assignee: Jim Ma
Fix For: jbossws-cxf-5.2.0.Final
I would like to deploy a WebService but I get an exception. The WSDL XSD file contains an
german character 'ä'. See:
Here is the part of the XSD:
<xs:simpleType name="Teilnehmerart">
<xs:restriction base="xs:string">
<xs:enumeration value="Privat"></xs:enumeration>
<xs:enumeration value="Geschäftlich"></xs:enumeration>
</xs:restriction>
</xs:simpleType>
The JBoss class org.jboss.ws.common.utils.AbstractWSDLFilePublisher
writes the imported WSDL file using a FileWriter at line 166 + 167.
FileWriter fw = new FileWriter(targetFile);
wsdlWriter.writeWSDL(subdef, fw);
In a next step this file is read again and results in an exception:
Invalid byte 2 of 3-byte UTF-8 sequence.
This is because the file is written in Cp1252 enconding together with an XML prolog
UTF-8 encoding. That is crazy and cannot work.
A workaround would be to set the Java file.encoding to UTF-8 but that is not what I
want.
There are two solutions:
I think it is better to create a binary OutputStream instead of creating a FileWriter.
The wsdlWriter offers two methods! The method with OutputStream argument would always
write XML files using a UTF-8 encoding.
An other way to fix that would be a bug fix to WSDL4J 1.6.3.
The WSDL4J method com.ibm.wsdl.xml.WSDLWriterImpl.writeWSDL(Definition wsdlDef, Writer
sink) does map default Java file.encoding to "UTF-8". That is sometimes wrong.
The class com.ibm.wsdl.util.xml.DOM2Writer should have an XmlEncodingMapping from
"Cp1252" to "Windows-1252". That would fix the problem also. But I
think it would be better to use always UTF-8 with the OutputStream method.
Best regards
Martin Both
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
3327
days inactive
3327
days old
jbossws-issues@lists.jboss.org
0 comments
1 participants
participants (1)
-
Martin Both (JIRA)