On 10/20/07, Chris Rose <[EMAIL PROTECTED]> wrote:
>
> More on this:
>
> It turns out that the client stub that is generated is creating code
> that looks like this:
>
> //Style is taken to be "document". No input parameters
> // according to the WS-Basic profile in this case we have to send an
> empty soap message
> org.apache.axiom.soap.SOAPFactory factory =
> getFactory(_operationClient.getOptions().getSoapVersionURI());
> env = factory.getDefaultEnvelope();
>
> However, what _works_ is to add this line (from the RPC calling style):
> env.getBody().addChild(factory.createOMElement("getVersion",
> "http://ws.management.ecourier.aciworldwide.com/";, ""));So could you over come the ealier issue? are you invoking the wsdl2java generated service with the wsdl2java generated client? In here since there is no body(correct case) either you should have used a soap action or addressing to dispatch the operation correctly. Amila. So, the client and the server disagree as to how this method should be > called. Moreover, PHP SOAP doesn't work with it either; it appears to > be non-interoperable. > > Has anyone else done this? How on earth does one create 0-parameter > methods in document/literal (wrapped) web service that will interoperate > with PHP, .NET, and Java? > > Chris Rose 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 = > > 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.
