JAX-WS Errors When SOAP Body Contains UTF-8 Specification

I developed a web service using JAX-WS (v2.1.3 - Sun JDK 1.6.0_05) deployed in WebLogic 10.3, which works great when I use Java client tools or SoapUI or other Web services testing tools. I need to use this service using Microsoft SQL Server 2005 Reporting Services, and I get the following error:

Failed to create SOAP message due to exception: XML read error: unexpected character content

SEVERE: Couldn't create SOAP message due to exception: XML reader error: unexpected character content: "?" com.sun.xml.ws.protocol.soap.MessageCreationException: Couldn't create SOAP message due to exception: XML reader error: unexpected character content: "?" at com.sun.xml.ws.encoding.SOAPBindingCodec.decode(SOAPBindingCodec.java:292) at com.sun.xml.ws.transport.http.HttpAdapter.decodePacket(HttpAdapter.java:276) at com.sun.xml.ws.transport.http.HttpAdapter.access$500(HttpAdapter.java:93) at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:432) at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244) at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:134) at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129) at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160) at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:75) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3498) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(Unknown Source) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2180) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2086) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1406) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) Caused by: com.sun.xml.ws.streaming.XMLStreamReaderException: XML reader error: unexpected character content: "?" at com.sun.xml.ws.streaming.XMLStreamReaderUtil.nextElementContent(XMLStreamReaderUtil.java:102) at com.sun.xml.ws.encoding.StreamSOAPCodec.decode(StreamSOAPCodec.java:174) at com.sun.xml.ws.encoding.StreamSOAPCodec.decode(StreamSOAPCodec.java:296) at com.sun.xml.ws.encoding.StreamSOAPCodec.decode(StreamSOAPCodec.java:128) at com.sun.xml.ws.encoding.SOAPBindingCodec.decode(SOAPBindingCodec.java:287) ... 22 more 

If I use an HTTP proxy to sniff out what SSRS sends to JAX-WS, I see EF BB BF as the beginning of the message body, and JAX-WS doesn't like it. If I delete special characters and resubmit the request using Fiddler, the web service is working.

Why will the JAX-WS explode with the standard UTF-8 specification? Is there any way around this problem? Any suggestions would be appreciated. Thanks

- Vinnie

+4
source share
2 answers

We had a similar problem writing a .Net client with a third-party Java.Net web service, including a byte byte, and the Java service threw an exception.

The third-party SOAP method took one line as an argument, and that line was an XML document (I love people who really don’t understand what problem SOAP is trying to solve!) By default .net added UTF-8 bytes to the XML document " payload, "which is strictly correct, but in practice causes problems.

In our case, we found two possible solutions from the end of the client (.net). I'm not sure how easy SQL Reporting will do it.

String.Trim () - xml should have been placed in a string before going to the soap method by calling .Trim () removed the byte order. Easily.

The second way was to slightly modify the UTF encoding settings in XmlWriterSettings, something like the following:

 XmlWriter xmlWriter = null; XmlWriterSettings settings = new XmlWriterSettings(); settings.Indent = true; settings.Encoding = new UTF8Encoding(false); xmlWriter = XmlWriter.Create(xmlSteam, settings); 

An important bit is the "new UTF8Encoding ( false ) encoding"; this argument is "encoderShouldEmitUTF8Identifier" and pretty much solves the problem.

+2
source

One workaround: add a filter to a web application that simply uses the specification before passing the request document to the JAX-WS service.

+1
source

All Articles