On 19-Oct-07, at 2:49 AM, Amila Suriarachchi wrote:
On 10/18/07, Chris Rose <[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).
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.
Good to know, but I am required to work with released versions of
Axis only, for now. Depending on the timing of a release vs. the
release of our product, I might be able to justify changing the version.
How stable are the nightlies? Can I drop one in as a production engine?
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]
--
Amila Suriarachchi,
WSO2 Inc.
--
Chris Rose
Developer Planet Consulting Inc.
424-4922 ext 339
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
