Re: document literal stub problems
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 parameternot 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;
myStringParamsome 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
Re: document literal stub problems
Problem is, I'm not a big C++ developer.
I'm more Java, but I'm trying to build a simple service client executable...
Is there any other way to get a more recent binary?
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 parameternot 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;
myStringParamsome 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
