On 10/19/07, Chris Rose <[EMAIL PROTECTED]> wrote: > > 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?
not a good idea. But you can do this. get a nighly build and generate the classes. and then create the service archive (.aar) from it deploy this service archive file in a released version server. So you use nighly build only to generate code. and you can test this generated code and veryfy any issues. > > > > > 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] > > -- Amila Suriarachchi, WSO2 Inc.
