axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bobby Lawrence <robe...@jlab.org>
Subject Re: document literal stub problems
Date Wed, 29 Apr 2009 21:55:38 GMT
Thanx Nadir.
I will checkout the code and try to build the binaries.
When is the next major release?

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

Jefferson Lab (www.jlab.org)

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




Nadir Amra wrote:
> Bobby,
>
> 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 <robertl@jlab.org> 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 
>>     
> 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
>> ----------------------------
>>
>>
>>
>>     
>
>   

Mime
View raw message