The service is a "handmade" web service, based on OSGI that uses Axis
1.3 only for (de)serializing. I have no direct control over the service,
but I will ask the developer of the service to change this. Thank you
for your quick answer Anne :-)
I have done some research and found a rather imprecise definition in
the WSDL SOAP 1.1 binding (http://www.w3.org/TR/2001/NOTE-
wsdl-20010315):
"[..] The value of the encodingStyle attribute MAY be used when the
use is literal to indicate that the concrete format was derived using
a particular encoding (such as the SOAP encoding), but that only the
specified variation is supported ("writer makes right")."
In the WSDL SOAP 1.2 binding extension (http://www.w3.org/Submission/
wsdl11soap12/) this combination is forbidden:
In WSDL 1.1 and SOAP 1.2 this combination is explicitly forbidden
(http://www.w3.org/Submission/wsdl11soap12/)
"The encodingStyle attribute (of type xs:anyURI), if present,
identifies the set of encoding rules used to construct the message.
This attribute MUST NOT be present unless the style attribute of the
wsoap12:binding element of the containing wsdl:binding has a value of
“rpc” and the use attribute on the containing wsoap12:body element
has a value of "encoded". The value of the encodingStyle attribute,
if present, MUST NOT be a relative URI."
On 01.09.2006, at 23:44, Anne Thomas Manes wrote:
If it's wrapped doc/literal, then your message should not contain an
element of type soapenc:string. Are you certain the that service is
using wrapped doc/literal? What SOAP stack is the service built with?
Anne
On 9/1/06, Christian Platta <[EMAIL PROTECTED]> wrote:
Hi,
I have the following:
Axis 1.3
A document literal (wrapped) service that I want to use
A client generated with WSDL2Java
My problem:
When I try to deserialize a response I get an exception that says
that no deserializer is found for string (namepsace http://
schemas.xmlsoap.org/soap/encoding/)
This problem is caused by the setEncoding(null) method that is
automatically generated by the WSDL2Java utility.
When I change it to call setEncoding
(org.apache.axis.Constants.URI_SOAP11_ENC) on the Call object,
everything works fine.
My question is now:
Can I generate a stub that contains setEncoding
(org.apache.axis.Constants.URI_SOAP11_ENC) automatically?
Can it be that this is an error of the web service? Why do I need a
SOAP encoding attribute for a document/literal service?
Regards
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]