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.
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'm currently using the ADB code generator, if it makes a difference.
--
Chris Rose
Developer Planet Consulting Group
(780) 577-8433
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
