Bobby, good question. I have been stating that I plan to release version 1.6 for a while now....and have not done so due to lack of time.
However, it is on my list of things to do. Maybe by end of year (unless a committer out there would like to volunteer to be release manager :-)) Nadir Amra Bobby Lawrence <robe...@jlab.org> wrote on 04/29/2009 04:55:38 PM: > [image removed] > > Re: document literal stub problems > > Bobby Lawrence > > to: > > Apache AXIS C User List > > 04/29/2009 04:57 PM > > Please respond to "Apache AXIS C User List" > > 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: robe...@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 <robe...@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: robe...@jlab.org > Office: (757) 269-5818 > Pager: (757) 584-5818 > ---------------------------- > > > > > >
