Amila Suriarachchi wrote:
On 10/18/07, *Chris Rose* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I'm trying to tune the code generation and our WSDL for service methods
with no parameters, which seems to be a fairly ill-documented process.
I've been all over the place, and I see that there are some bugs in
connection with this (AXIS-3199) which I've started watching, but I
hoped that someone in the community at large can offer some insight into
this.
The method looks like this:
public VersionBean getVersion ();
Our WSDL (as noted in my comment on the bug report) looks like this:
<xs:element name='getVersion'>
<xs:complexType />
</xs:element>
<xs:element name='getVersionResponse' type='tns:getVersionResponse'/>
<xs:complexType name='getVersionResponse'>
<xs:sequence>
<xs:element minOccurs='0' name='return' type='ns2:versionBean'/>
</xs:sequence>
</xs:complexType>
<xs:complexType name='version'>
<xs:sequence>
<!-- ... various version fields -->
</xs:sequence>
</xs:complexType>
<xs:complexType name='versionBean'>
<xs:complexContent>
<xs:extension base='ns1:version'>
<xs:sequence/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<message name='Service_getVersion'>
<part element='ns1:getVersion' name='parameters'/>
</message>
<message name='Service_getVersionResponse'>
<part element='ns1:getVersionResponse' name='getVersionResponse'/>
</message>
<portType name='Service'>
<operation name='getVersion' parameterOrder='getVersion'>
<input message='ns1:Service_getVersion'/>
<output message='ns1:Service_getVersionResponse'/>
</operation>
</portType>
What I'd like to see in the generated ServiceSkeletonInterface is a
getVersion() method with the same signature pattern: No parameters.
What I get, instead, is a getVersion (GetVersion getVersion) method,
which is awkward, as we use a reflection-based tool to map these
methods
to their implementation counterparts. Divergence between actual
implementation and interface is a problem, then.
I've tried removing the <input/> message in the operation element, but
that results in no service whatsoever being generated.
this is a problem with the axis2 adb unwrapping. as a work around you
can remove the
part element from the input message. (Then nothing goes on the soap boady).
That works from the service side; it generates interfaces that _look_
right, now, but when I invoke the methods in an axis2 client, I get this:
rg.apache.axis2.AxisFault: The endpoint reference (EPR) for the
Operation not found is
http://localhost:8080/ecourier/services/OperationsManagerService and the
WSA Action =
at
org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:486)
at
org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:343)
at
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389)
at
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211)
at
org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at
com.aciworldwide.ecourier.management.ws.client.OperationsManagerServiceStub.findAllApplications(OperationsManagerServiceStub.java:763)
at GetVersion.main(GetVersion.java:69)
How can I make the client build the correct message?
A second problem with the code generation: We run the schema compiler
multiple times, because we isolate our web services into individual
deployment aars which are then assembled at deployment time into a final
set of services. What we end up with is things like the aforementioned
GetVersion class, but with an integer suffix that is... frustrating,
especially when the fact that it's generated in a different package
each
time is taken into account. It looks like the JavaBeanWriter is doing
this, but the name generation behaviour in it is not amenable to
overriding since it depends extensively on private variables. Has
anyone got a better bean writer implementation they can suggest?
I fixed this issue. please have a look at with a nighly build.
I'm currently using the ADB code generator, if it makes a difference.
--
Chris Rose
Developer Planet Consulting Group
(780) 577-8433
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
--
Amila Suriarachchi,
WSO2 Inc.
--
Chris Rose
Developer Planet Consulting Group
(780) 577-8433
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
