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. 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.
