Community

JBESB-3279 is closed.

Kev and I continued this discussion over IM, and decided on the following, which I implemented in the fix:

1. Even though WS Basic Profile has rules about Acceptable WSDL Character Encodings, we will do our best to handle those situations - where we can - so that our code will output compliant WSDL.
2. WSDL can be read in using internal://, classpath://, file://, http:// and https:// protocols.  In the case of internal://, which is provided by JBossWS, it is already UTF-8.  In the case of http:// or https://, we will try to look for the charset specified by the HTTP response header "Content-Type".  If that is specified, we will try to convert from that specified encoding to UTF-8.
3. A new SOAPProxy action property has been added: wsdlCharset (the camel case property name was chosen so it is consistent with the wsdlTransform property).  If the developer specifies the wsdlCharset property, the WSDL will be read in using that encoding, and we will try to convert from that specified encoding to UTF-8.  The presence of that property takes priority over the Content-Type header in the case of http:// or https://.
4. The contract JSP (in the case of using JBR/HTTP gateway) and the HttpGatewayServlet both now always output UTF-8.
5. The Programmer's Guid has been updated to include a description about the new wsdlCharset property.

Please refer to the jira item for a test case as well as a screenshot of some Russian characters in Unicode.

Vitaliy, with this fix, all you should have to do is add this property to your SOAPProxy action:

<property name="wsdlCharset" value="Cp1251"/>

I have tested the fix on both AS4+Java5 and AS5+Java6.  I also ran a clean integration build.