axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nadir Amra <>
Subject Re: document literal stub problems
Date Wed, 29 Apr 2009 21:45:44 GMT

If you are using existing binaries to try out Axis C++, then you will have 
problems.  You should build new binaries from SVN and try again.  I 
believe VC++ project or ant can be used to build the new binaries.

Yes, we plan on releasing new binaries.....some time. 

Nadir Amra

Bobby Lawrence <> wrote on 04/29/2009 04:31:33 PM:

> [image removed] 
> document literal stub problems
> Bobby Lawrence 
> to:
> axis-c-user
> 04/29/2009 04:32 PM
> Please respond to "Apache AXIS C User List"
> 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 
> service in your SOAP body.  Except that you still have to add your 
> 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 
> 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="">
>     <myStringParam>some string</myStringParam>
> </ns1:echoString>
> For a document/literal service, the SOAP body should look like this:
> <ns1:echoString xmlns:ns1="">
>     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 
> 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 (
>  Email:
> Office: (757) 269-5818
>  Pager: (757) 584-5818
> ----------------------------

View raw message