Hello there!

While analyzing the code that generates the stub class
(org.apache.axis.wsdl.toJava.JavaStubWriter) i found out that the
typeMappings get lost when WSDL is defined using LITERALS in the binding.
Used encoding instead of literals and RPC instead of DOCUMENT in STYLE. No
client side code for definition of serializers/deserializers was needed
anymore.

I spent a 10 hours playing round and digging in news groups till i found the
posting below. Take this
shortcut instead!

Here an example of a WSDL file without literals

    <wsdl:binding name="companyTestBinding" type="tns:companyTestPortType">
        <soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
        <wsdl:operation name="getSymbol">
            <soap:operation style="rpc"/>
            <wsdl:input>
                <soap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
                    namespace="http://www.company.name/companyTest/binding";
                    parts=""
                    use="encoded"/>
            </wsdl:input>
            <wsdl:output>
                <soap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
                    namespace="http://www.company.name/companyTest/binding";
                    parts=""
                    use="encoded"/>
            </wsdl:output>
        </wsdl:operation>
        <wsdl:operation name="getProfile">
            <soap:operation

soapAction="capeconnect:companyTest:companyTestPortType#getProfile"
                style="rpc"/>
            <wsdl:input>
                <soap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
                    namespace="http://www.company.name/companyTest/binding";
                    use="encoded"/>
            </wsdl:input>
            <wsdl:output>
                <soap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
                    namespace="http://www.company.name/companyTest/binding";
                    parts=""
                    use="encoded"/>
            </wsdl:output>
        </wsdl:operation>
    </wsdl:binding>

----------------------------------------------------------------------------
-----------------------


Hi Everyone:

I actually discovered the cause of my problem, and searching through this
list's archives, I believe the same solution would apply to many others who
have experienced similar issues. In the end, the solution was so simple that
I'm almost embarrassed to post it here.

The problem had nothing to do with Castor (de)serialization or the
AxisClient class. The problem lie in the fact that I was using a
ClientHandler to support WSSE [http://axis-wsse.sourceforge.net/].
Nevertheless, the ClientHandler itself was not the problem (in fact, I
highly recommend it for simple Username/Password WSSE support). It was the
fact that the "setClientHandlers" method was called that was the problem.
This member of the org.apache.axis.client.Call class ends up calling its
sibling member "setSOAPService" with a new SOAPService object. The
SOAPService object is set as a private member of the Call object [with a
variable name of "myService"].

This is all fine until the Call.invoke() method is executed by the SoapStub.
It is within the logic of this method that "myService" is set to the
MessageContext object. NOW THE PROBLEM BEGINS, for it is within the
"setService" member of the MessageContext object that the MessageContext's
encoding type is set to SOAP encoding. Since the service was using SOAP
v1.1, the actual value of the encoding became:
"http://schemas.xmlsoap.org/soap/encoding/";. However, if we refer back to
the SoapStub object that was generated by WSDL2Java, we see that the
encoding under which the TypeMappingRegistry was created was "null". The
TypeMappingRegistry that had been created is no longer visible to objects
that are now attempting to retrieve TypeMappings for the SOAP1_1 encoding.

Perhaps it should have been obvious to me that I would have to edit the
encoding within the SoapStub object simply because I added a ClientHandler,
but it was not. Regardless, the solution was to change the following line in
the "createCall" member of the SoapStub from:

_call.setEncodingStyle(null);

to:


_call.setEncodingStyle(org.apache.axis.soap.SOAPConstants.SOAP11_CONSTANTS.g
etEncodingURI());


Reply via email to