We've been having a few issues with the encoding of the response message being sent by our web service.
The request message being received by our web service is
<?xml version="1.0" encoding="UTF-8"?>
The problem is in the response message, which is
Obviously, that doesn't look quite right. Can anybody explain why all these extra numbers are appearing (seamingly randomly) in the output, and also why the output doesn't have the <?xml version="1.0" encoding="UTF-8"?> header tag in it?
We've been using the MSSoapT tool to 'listen' to the request and response messages, but using the .NET WebService Studio tool (we are only using Java/JBoss, but the company developing the webservice we're responding to/calling our web service are using .NET hence why we're using these tools) we view a somewhat different version of the respose message:
ResponseCode: 200 (OK)
X-Powered-By:Servlet 2.4; JBoss-4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000)/Tomcat-5.5
Date:Fri, 25 Aug 2006 13:03:41 GMT
<?xml version="1.0" encoding="utf-16"?>
Now, this seems to suggest that we're using UTF-16 for the encoding, which we're not! As far as I'm aware, all the defaults are UTF-8, and just to be totally sure, when I run the JBoss server we are using the "-Dfile.encoding=utf-8" option, and when we compile our web service and test client we using the "-encoding utf-8". None of our config xml files mention utf-16 anywhere, so I really don't know why the response appears to be encoded in utf-16.
For info, I'm using Java EE 5 SDK & JBoss 4.0.4, and its a document literal web service. We get the same problem whether we are running the JBoss server on a Windows XP Pro machine (localhost) or a linux (SLES10) server.
If anyone can give me any explanation as to why
a) Why we are getting these random numbers appearing in the output
b) Why it appears to be using utf-16 encoding
...I'd be very appreciative, as I've been pulling my hair out on this one for a few days now. If you need any other information like the WSDL etc. then just say and I'll post it.
Looks like you are hitting on the interoperability related issue between MS-SOAP and j2ee webservices....
attached below is the link which talks about different interoperability issues:
Improve interoperability between J2EE technology and .NET, Part 1
WSDL, RPC/encoded style, and WS-I conformance
I tried invoking j2ee webservice from .net...it worked ok...
Attached below is the link which has the working code...
Thanks for your reply.
I've done a little more investigating, and my current thoughts are that the problem stems from the fact that the WSDL we are using to generate our J2EE web service was generated from some .NET code. Thats is my current line of investigation, though I'm still unsure about exactly what is causing the problem.
even when it says utf-16 in the encoding within the response it does not matter.
The one specified in the content character encoding http header takes precedence. which in your case is utf-8 as you had configured.
why is then utf-16 there? probably because .net uses that by default and jboss can parse utf-16 in the request but uses utf-8 in the response just as you have configured it to do. It does not care to change the encoding information within the content (anyway it does not matter).
why the junk chars? no idea. probably it is the limitation of the tool that you are using to test the same.
OK, so after a bit of digging, I've made some progress.
The 'junk' characters aren't junk at all! They are just control characters for the 'chunked' transfer-encoding that JBoss appears to be using! It would appear that Java tools (such as my Java test client, and the SoapUI tool) can understand messages sent using chunked encoding (hence why we'd never seen this 'problem' before), but as soon as we use a .NET tool, such as our suppliers client or the MSSoapT tool, they don't seem to understand the output, and hence display the control characters as part of the message.
So, I suppose the next question is, does anybody know anything about the different setting for transfer-encoding, and more specifically how I can use something other than 'chunked' in JBoss?
OK, I found the solution (and cause) of the problem. Apparently .NET doesn't implement HTTP/1.1 correctly, so needs the following line adding to the connector element of the Tomcat server.xml file:
restrictedUserAgents="^.*MS Web Services Client Protocol.*$"
As with everything, once you know what to look for, you find it! There is an entry in the JBoss Wiki about it ;-)