On 10/19/07, Chris Rose <[EMAIL PROTECTED]> wrote:
>
>
>
> 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 =
this seems to be a dispatching problem. since you have change the context
root please check
whether the requests correctly goes to the axis2 servlet.
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]
>
>
--
Amila Suriarachchi,
WSO2 Inc.
