Mailing-List: contact axis-c-user-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C User List" <axis-c-user@ws.apache.org>
Received-SPF: pass (athena.apache.org: domain of robertl@jlab.org designates
 129.57.35.69 as permitted sender)
Message-ID: <49F8C735.2020201@jlab.org>
Date: Wed, 29 Apr 2009 17:31:33 -0400
From: Bobby Lawrence <robertl@jlab.org>
Organization: Jefferson Lab (jlab.org)
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: axis-c-user@ws.apache.org
Subject: document literal stub problems
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ok - I see a lot of people complaining about getting the C++ client talking to an Axis Java service and running into serialization issues (the server side complaining about unknown elements).
I am running into the same issue, but I think I know what the real problem is.

First off, Axis requires that you call Stub.setOperation() or nothing will exist in the Body of your SOAP envelope.  Ok - that all fine an dandy because you end up with an XML element with the name of the 
service in your SOAP body.  Except that you still have to add your parameter.
Well - parameters in document literal services don't get wrapped within another element.
If you have a doc/lit service that has an operation called "echoString" and the parameter type is an xsd:string, the "echoString" element in the SOAP body is understood to contain the string parameter....not a separate element that contains the string parameter.

When you add a parameter in the Stub (usually generated for you), Axis C++ adds another element to the 'operation/method' element of the SOAP body, so you end up with something like this (not exactly because of other Stub generation issues discussed later):

<ns1:echoString xmlns:ns1="http://some.namespace.org">
    <myStringParam>some string</myStringParam>
</ns1:echoString>

For a document/literal service, the SOAP body should look like this:

<ns1:echoString xmlns:ns1="http://some.namespace.org">
    some string
</ns1:echoString>

At first I thought it had something to do with my generated Stub.
When I first used WSDLWs to generate my Stub, it ignored my parameters completely.
This is because of a un-documented option to the tool -w (for whether or not to generate "wrapped" types).  Well - this option is referenced in the Axis C++ webpage for the tool, but you can't use the option because 
of the code in the org.apache.axis.wsdl.wsdl2ws.WSDL2Ws Java tool.

if(clargparser.isSet("w") && !"wrapped".equalsIgnoreCase(clargparser.getOptionBykey("w")))
{
	usage();
        return false;
}

Essentially, if you pass the -w option, anything except "wrapped" will abort processing of the tool, even though "nonwrapped" is an option.
I had to create my own WSDL2Ws tool to get around this issue, but it doesn't solve the problem.
Even with the "nonwrapped" option, the method calls to the Stub have the correct signature now, but the Stub still generates a wrapped element with the "addParameter" method invocation on the Call.

I can't find a way around this.  Maybe if I checked out the Axis C++ source code and modified it and built it myself.
Every other client I've created for this type of service works except the Axis C++ client...

Also - the generated Stubs have a slight bug in them in that the method "checkFault" on the Call object should take in the service's namespace as the second parameter, but the generated code puts the endpointURI in for this param.
I haven't gotten far enough to find out if this is an issue, but it probably is...

Anyway - I just wanted to let folks know that this is probably a bug in the Axis C++ "Call" object design.
There needs to be a way to add un-wrapped parameters to an operation to support document/literal services.

-- 
----------------------------
Bobby Lawrence
MIS Application Developer

Jefferson Lab (www.jlab.org)

 Email: robertl@jlab.org
Office: (757) 269-5818
 Pager: (757) 584-5818
----------------------------