Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Web Service Exception WSAD v5.1

3 views
Skip to first unread message

ti...@bellatlantic.net

unread,
Oct 16, 2003, 11:46:28 AM10/16/03
to
I've developed a set of Java Bean Web Services on WSAD v5.1 (w/ interim fix 001) on Windows 2000 Professional.
I am trying to access the Web Service from a VB6 client using the Microsoft SOAP Toolkit. When I call any
web service from the Microsoft SOAP Toolkit (2.0 and 3.0), I receive the following Exception:

Exception = org.xml.sax.SAXException
Source = com.ibm.ws.webservices.engine.SOAPPart.getAsSOAPEnvelope
probeid = 709
Stack Dump = java.io.UnsupportedEncodingException: "UTF-8"
at com.ibm.ws.webservices.engine.encoding.DeserializationContextImpl.parse(DeserializationContextImpl.java:268)
at com.ibm.ws.webservices.engine.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:698)
at com.ibm.ws.webservices.engine.Message.getSOAPEnvelope(Message.java:440)
at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCSOAPHandler.checkSOAPSemantics(JAXRPCSOAPHandler.java:218)
at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCSOAPHandler.invokeServerRequestHandler(JAXRPCSOAPHandler.java:188)
at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandler$1.invoke(JAXRPCHandler.java:232)
at com.ibm.ws.webservices.engine.PivotHandlerWrapper.invoke(PivotHandlerWrapper.java:203)
at com.ibm.ws.webservices.engine.handlers.WrappedHandler.invoke(WrappedHandler.java:61)
at com.ibm.ws.webservices.engine.PivotHandlerWrapper.invoke(PivotHandlerWrapper.java:217)
at com.ibm.ws.webservices.engine.PivotHandlerWrapper.invoke(PivotHandlerWrapper.java:217)
at com.ibm.ws.webservices.engine.WebServicesEngine.invoke(WebServicesEngine.java:258)
at com.ibm.ws.webservices.engine.transport.http.WebServicesServlet.doPost(WebServicesServlet.java:835)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at com.ibm.ws.webservices.engine.transport.http.WebServicesServletBase.service(WebServicesServletBase.java:341)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(StrictServletInstance.java:110)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service(StrictLifecycleServlet.java:174)
at com.ibm.ws.webcontainer.servlet.IdleServletState.service(StrictLifecycleServlet.java:313)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service(StrictLifecycleServlet.java:116)
at com.ibm.ws.webcontainer.servlet.ServletInstance.service(ServletInstance.java:283)
at com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch(ValidServletReferenceState.java:42)
at com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch(ServletInstanceReference.java:40)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispatch(WebAppRequestDispatcher.java:948)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppRequestDispatcher.java:530)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:176)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java:79)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.java:201)
at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:71)
at com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:182)
at com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service(OSEListener.java:334)
at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest(HttpConnection.java:56)
at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:610)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:431)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:593)

This web service works fine when called from any of the following clients:
* The Websphere Web Services Explorer
* The generated Web Services Test Client from the Web Service wizard
* A VB.NET application.

Using tcpmon, I noticed that the Microsoft SOAP toolkit sends Content-Type: text/xml; charset="UTF-8" (with quotes).
Every other client (above) sends Content-Type: text/xml; charset=utf-8 (without quotes)

A sample call from MS Soap Toolkit:

POST /myapp/services/myservice HTTP/1.1
SOAPAction: ""
Content-Type: text/xml; charset="UTF-8"
User-Agent: SOAP Toolkit 3.0
Host: localhost
Content-Length: 615
Connection: Keep-Alive
Cache-Control: no-cache
Pragma: no-cache

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<SOAP-ENV:Envelope xmlns:SOAPSDK1="http://www.w3.org/2001/XMLSchema"
xmlns:SOAPSDK2="http://www.w3.org/2001/XMLSchema-instance"
xmlns:SOAPSDK3="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<getVersionList xmlns="http://myapp.com">
<repositoryId xmlns:SOAPSDK4="http://myapp.com"></repositoryId>
<objectId xmlns:SOAPSDK5="http://myapp.com">090005788000a4aa</objectId>
</getVersionList>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

A sample call from the Web Services Explorer:

POST /myapp/services/myservice HTTP/1.0
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: 447
SOAPAction: ""

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:q0="http://myapp.com" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<q0:getVersionList><q0:repositoryId></q0:repositoryId><q0:objectId>090005788000a4aa</q0:objectId></q0:getVersionList>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

To debug the problem, I created a simple HTTP client to send the same SOAP request with and without
quotes around the UTF-8 on the Content-Type header. I received the exception only when I send quotes.

I believe the quotes are valid based on IETF XML Media Type RFC's (RFC2376 and RFC3023), and the examples
shown in the WSAD v5.1 help (e.g., "Example: Caching Web Services"). I've seen some javadoc that suggests it is an error to put quotes around
the charset but it's all throughout the documentation and seems to have been supported at some point in time.

Unfortunately, the Microsoft SOAP toolkit doesn't allow you to change the Content-Type header.
To make my life simple, I'd like to use the high-level API from the Microsoft SOAP toolkit without
having to write any custom code to reduce complexity.

I've tried the following:
* Backing out Interim Fix 001
* set the JVM client.encoding.override property in the test environment to UTF-8
* Turning on Automatic Response/Request Encoding
* Document Literal and RPC encoded Web Service

Is this a bug in Websphere Studio or is there something I can change or add to get around this problem?

Any suggestions anyone has would be greatly appreciated. I've nearly run out of ideas on how to address this problem short of writing a custom client that does simple HTTP POSTs.

Thanks.


tibors

unread,
Oct 21, 2003, 7:12:21 PM10/21/03
to
hi
I think we go through the same hell.
I use the most recent Eclipse with the newest WSDK from IBM;
(which includes WAS Express 5.02 as a Test Environment)
The WS engine based on JAX-RPC..etc standards, Axis was built into the server core (no Axis Java packages are present). Supports latest WS-I.
VB6 client with MS-SOAP 3 is not WS-I compliant as I understood however it should be able to handle at least simple Document/Literal cases.
What is interesting enough when I use a Java proxy client the <xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope.. beginning doesn't seem to be a problem;
The VB6 client's <xml version="1.0" encoding="UTF-8" standalone="no"?>
<SOAP-ENV:Envelope.. lines immediately comes back with java.io.UnsupportedEncodingException: "UTF-8" message from the server.
By the way It comes in a well formed soap envelope like:
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><soapenv:Fault><faultcode xmlns:wasws="http://websphere.ibm.com/webservices/" xmlns="">wasws:Server.generalException</faultcode><faultstring xmlns=""><![CDATA[java.io.UnsupportedEncodingException: "UTF-8"]]></faultstring><detail xmlns=""><stackTrace xmlns="http://websphere.ibm.com/webservices/"><![CDATA[java.io.UnsupportedEncodingException: "UTF-8" at sun.io.Converters.getConverterClass(Converters.java:121)

...and so on
I use NetTool from capescience.com for tuneling; it also includes an HTTP tool so I can try stuff with the same program: If I repost the VB6 client generated soap envelop with all the proper headers and without the above mentioned encoding="UTF-8" standalone="no" xml header like:
<?xml version="1.0"?>
It goes trough with no problem, I get a valid response to the VB client from the WAS web service.
NOW All I have to do is to tell to the MSSOAP API not to include them. Unfortunately I cannot do that.
Even when I use the low level API.
I am at the same point where you are now. Let's keep each other posted if something comes up. I have no clue how to proceed.
cheers

tibors

unread,
Oct 21, 2003, 7:28:51 PM10/21/03
to
hi
I think we go through the same hell.
I use the most recent Eclipse with the newest WSDK from IBM;
(which includes WAS Express 5.02 as a Test Environment)
The WS based on JAX-RPC..etc standards, Axis was built into the server (no Axis Java packages are present). Supports latest WS-I.

VB6 client with MS-SOAP 3 is not WS-I compliant as I understood however it should be able to handle at least simple Document/Literal cases.
What is interesting enough when I use a Java proxy client the <code> < xml version="1.0" encoding="UTF-8"? >
<soapenv:Envelope..</code> beginning doesn't seem to be a problem;
The VB6 client's <code> < xml version="1.0" encoding="UTF-8" standalone="no"? >"
<SOAP-ENV:Envelope..</code> lines immediately come back with java.io.UnsupportedEncodingException: "UTF-8" message

By the way It comes in a well formed soap envelope like:
<code> < ?xml version="1.0" encoding="UTF-8"? >

< soapenv : Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
< soapenv: Body >< soapenv:Fault >
< faultcode xmlns:wasws="http://websphere.ibm.com/webservices/"
xmlns="">wasws:Server.generalException</faultcode>
< faultstring
xmlns="">< ![CDATA [java.io.UnsupportedEncodingException: "UTF-8"]]></faultstring >
< detail xmlns=""><stackTrace
xmlns="http://websphere.ibm.com/webservices/">
< ! [CDATA[java.io.UnsupportedEncodingException: "UTF-8"
at sun.io.Converters.getConverterClass(Converters.java:121)
</code>
...and so on
I use NetTool from capescience.com for tuneling; it also includes an HTTP tool so I can try stuff with the same program; If I repost the VB6 client generated message with all the proper headers and without the above mentioned encoding="UTF-8" standalone="no" xml header so it stays as:
<code>< ?xml version="1.0"? > </code>

ti...@bellatlantic.net

unread,
Oct 21, 2003, 8:46:56 PM10/21/03
to
I found a workaround to my problem even though I believe this is a bug in Websphere. I created a javax.servlet.Filter (feature of Servlets 2.3) which removes the quotes from the charset (encoding) in the ServletRequest parameter (getContentEncoding, setContentEncoding) in the doFilter method. The Filter is applied to the WebServicesServlet in the web.xml settings. WSAD generates a warning because the servlet isn't defined in the web.xml file but it works.

I don't know if this would solve your problem. To pinpoint my problem I only tried removing the quotes from the Content-Type header and not from the XML declaration like you did.

tibors

unread,
Oct 21, 2003, 9:42:49 PM10/21/03
to
Actually both solutions work when we simulate the SOAP POST;
You either remove the encoding="UTF-8" from the XML header or
remove the quotes from the http header; I didn't find the solution because I wanted to remove the part from the XML header. I use your solution to filter it out.
Thanks.

0 new messages