You are right -- put axis application into $CATALINA_HOME/webapps/axis/WEB-INF/lib $CATALINA_HOME/webapps/axis/WEB-INF/classes
Then do deploy by from the same machine : java org.apache.client.AdminClient deploy.wsdd -Feng -----Original Message----- From: Patrick Quinn [mailto:[EMAIL PROTECTED] Sent: Friday, June 17, 2005 3:47 AM To: axis-user@ws.apache.org; Anne Thomas Manes Subject: RE: No such operation error - malformed WSDL? Ok. Thanks for all the good advice Anne (and Feng), I will press our customer to use your revised wrapped style WSDL, which certainly works. On a separate note, I do not have a web service background and have got my SOAP services working by putting the classes into jarfiles; placing these in $CATALINA_HOME/common/lib; and pointing the CLASSPATH at them. Is this acceptable, or should I be looking with Axis to structure below webapps/axis/WEB-INF? I have been asked to supply WAR files to deposit here. Regards Pat -----Original Message----- From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] Sent: 17 June 2005 01:18 To: Patrick Quinn Subject: Re: No such operation error - malformed WSDL? Many SOAP systems are tolerant of malformed WSDL, but others aren't. So even though the WDSL may have worked with their Windows app, it would certainly cause problems when trying to interoperate. As you experienced... On 6/16/05, Patrick Quinn <[EMAIL PROTECTED]> wrote: > Thanks Anne for the clarity. > > I have been told that the WSDL works and txns can be sent with it in a > Windows environment (I am Solaris based). I will chase up more details > on this as I trust far more what you tell me than the client I am > dealing with. > > Regards > > pat > > -----Original Message----- > From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] > Sent: 16 June 2005 13:11 > To: Patrick Quinn > Subject: Re: No such operation error - malformed WSDL? > > > The Wrapped style *is* document/literal -- but it uses a convention > that makes it easier for the server to dispatch requests, and it makes > it easier for clients to consume it. > > If you don't use the wrapped style, then you must tell Axis how to map > the incoming message to a specific method, and clients must use beans > rather than parameters (not the other way around). > > The use of type="xsd:string" in a message part definition is not > permitted with document/literal, so your customer should have had > trouble with the original WSDL. > > Regards, > Anne > > On 6/16/05, Patrick Quinn <[EMAIL PROTECTED]> wrote: > > Hi Anne > > > > Many thanks for taking the time to review the WSDL and amend. It is > > really helpful to an Axis newbie like me. > > > > I have run this WSDL and it works fine. > > > > My only problem is that the original is a customer-generated WSDL, > > and > > > they may already have generated the client code to pass a bean > > (rather > > > than strings). > > > > Is using document/literal to be avoided at all costs, since it is > > too complicated? > > > > I will do what I can to convince the customer to adopt the wrapped > > style, but if there is any way that I can adhere still to doc/lit > > then > > > this would avoid extra development costs to the customer. > > > > Thanks again for looking at this. > > > > pat > > > > -----Original Message----- > > From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] > > Sent: 16 June 2005 01:14 > > To: axis-user@ws.apache.org > > Subject: Re: No such operation error - malformed WSDL? > > > > > > I finally allocated to review your WSDL. You have one error -- when > > using document/literal, your message <part> definitions must > > reference > > > an element, not a type. And as I said before, it works a lot better > > if > > > you use wrapped style rather than document style. > > > > Here's an updated WSDL that fixes the error and uses the wrapped > > convention. > > > > <?xml version="1.0" encoding="UTF-8"?> > > <wsdl:definitions > > xmlns="http://schemas.xmlsoap.org/wsdl/" > > xmlns:impl="urn:xml-soapadapter" > > xmlns:intf="urn:xml-soapadapter" > > xmlns:tns="urn:ProvidentProvisioningTNS" > > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" > > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" > > targetNamespace="urn:ProvidentProvisioningTNS" > > name="urn:ProvidentProvisioning"> > > <wsdl:types> > > <xsd:schema elementFormDefault="qualified" > > targetNamespace="urn:ProvidentProvisioningTNS"> > > <xsd:element name="ProvisioningTaskRequestOperation"> > > <xsd:complexType> > > <xsd:sequence> > > <xsd:element minOccurs="0" maxOccurs="1" > > name="REQUESTID" type="xsd:string"/> > > <xsd:element minOccurs="0" maxOccurs="1" name="SOTYPE" > > type="xsd:string"/> > > <xsd:element minOccurs="0" maxOccurs="1" name="PRIORITY" > > type="xsd:string"/> > > <xsd:element minOccurs="0" maxOccurs="1" name="RECOVERY" > > type="xsd:string"/> > > <xsd:element minOccurs="0" maxOccurs="1" name="XML_SO" > > type="xsd:string"/> > > </xsd:sequence> > > </xsd:complexType> > > </xsd:element> > > <xsd:element name="ProvisioningTaskResponse"> > > <xsd:complexType> > > <xsd:sequence> > > <xsd:element name="ProvisioningTaskReturn" > > type="xsd:string"/> > > </xsd:sequence> > > </xsd:complexType> > > </xsd:element> > > </xsd:schema> > > </wsdl:types> > > <message name="ProvisioningTaskRequestMessage"> > > <part name="parameters" > > element="tns:ProvisioningTaskRequestOperation"/> > > </message> > > <message name="ProvisioningTaskAckMessage"> > > <part name="parameters" element="tns:ProvisioningTaskResponse"/> > > </message> > > <portType name="ProvisioningTaskRequestPortType"> > > <operation name="ProvisioningTaskRequestOperation"> > > <input message="tns:ProvisioningTaskRequestMessage"/> > > <output message="tns:ProvisioningTaskAckMessage"/> > > </operation> > > </portType> > > <binding name="ProvisioningTaskRequestSoapBinding" > > type="tns:ProvisioningTaskRequestPortType"> > > <soap:binding style="document" > > transport="http://schemas.xmlsoap.org/soap/http"/> > > <operation name="ProvisioningTaskRequestOperation"> > > <soap:operation > > > soapAction="ProvidentProvisioningTNS/ProvisioningTaskRequestOperation" > /> > > <input> > > <soap:body use="literal"/> > > </input> > > <output> > > <soap:body use="literal"/> > > </output> > > </operation> > > </binding> > > <service name="ProvisioningService"> > > <documentation>Provident Provisioning Service</documentation> > > <port name="ProvisioningTaskRequestPort" > > binding="tns:ProvisioningTaskRequestSoapBinding"> > > <soap:address > > location="http://localhost:8880/axis/services/ProvidentProvisioning"/> > > </port> > > </service> > > <!-- message declns --> > > <!-- port type declns FINISHED --> > > <!-- binding declns FINISHED --> > > <!-- service decln FINISHED --> </wsdl:definitions> > > > > On 6/15/05, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > > > I just grabbed the WSDL operation name, but perhaps your Java > > > method > > > > name is different? The "name" attribute should specify the Java > > > method > > > > > name. > > > > > > Anne > > > > > > On 6/15/05, Patrick Quinn <[EMAIL PROTECTED]> wrote: > > > > Thanks Anne, Feng > > > > > > > > You have both given me food for thought and I won't give up. > > > > > > > > Anne, I did try adding the operation definition as you > > > > suggested. See below: > > > > > > > > <deployment > > > > xmlns="http://xml.apache.org/axis/wsdd/" > > > > xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> > > > > <!-- Services from ProvisioningService WSDL service --> > > > > <parameter name="wsdlServicePort" > > value="ProvisioningTaskRequestPort"/> > > > > <parameter name="className" > > > > value="ProvidentProvisioningTNS.ProvisioningTa > > > > skRequestSoapBindingSkeleton"/> > > > > <parameter name="wsdlPortType" > > value="ProvisioningTaskRequestPortType"/> > > > > <parameter name="allowedMethods" value="*"/> > > > > <operation name="ProvisioningTaskRequestOperation" > > > > qname="ns:ProvisioningTaskRequest" > > > > /> > > > > <typeMapping > > > > xmlns:ns="urn:ProvidentProvisioningTNS" > > > > qname="ns:ProvisioningTaskRequest" > > > > > > type="java:ProvidentProvisioningTNS._ProvisioningTaskRequest" > > > > > > serializer="org.apache.axis.encoding.ser.BeanSerializerFactory" > > > > > > deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory" > > > > encodingStyle="" > > > > /> > > > > </service> > > > > </deployment> > > > > > > > > > > > > But I now get the following error: > > > > > > > > > > > > Exception in thread "main" AxisFault > > > > faultCode: > > > > {http://schemas.xmlsoap.org/soap/envelope/}Server.userException > > > > faultSubcode: > > > > faultString: org.apache.axis.InternalException: > > java.lang.Exception: Couldn't find a matching Java operation > > for WSDD operation "ProvisioningTaskRequestOperation" (0 > > args) > > > > faultActor: > > > > faultNode: > > > > faultDetail: > > > > {http://xml.apache.org/axis/}stackTrace: AxisFault > > > > faultCode: > > {http://schemas.xmlsoap.org/soap/envelope/}Server.userException > > > > faultSubcode: > > > > faultString: org.apache.axis.InternalException: > > java.lang.Exception: Couldn& > > > > ;apos;t find a matching Java operation for WSDD operation > > &quot;Provisioning > > > > TaskRequestOperation&quot; (0 args) > > > > faultActor: > > > > faultNode: > > > > faultDetail: > > > > org.apache.axis.InternalException: java.lang.Exception: Couldn't > > find a matching > > > > Java operation for WSDD operation > > "ProvisioningTaskRequestOperation" > > > > (0 args) > > > > > > > > > > > > Is this something obvious, or is it better to take Feng's advice > > > > and > > > > > > build from scratch using Java2WSDL? > > > > > > > > Thanks again, > > > > > > > > Pat > > > > > > > > > > > > -----Original Message----- > > > > From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] > > > > Sent: Wed 15/06/2005 18:27 > > > > To: axis-user@ws.apache.org > > > > Cc: > > > > Subject: Re: No such operation error - malformed WSDL? > > > > > > > > > > > > > > > > Pat, > > > > > > > > You're correct -- you need to add an <operation> > > > > definition > > to your > > > > WSDD to help Axis map the <ProvisioningTaskRequest> > > > > message > > to the > > > > ProvisioningTaskRequestOperation method. > > > > > > > > The format of the <operation> definition is: > > > > > > > > <operation name="ProvisioningTaskRequestOperation" > > > > qname="ns:ProvisioningTaskRequest" > > > > /> > > > > > > > > (If you used wrapped style, you wouldn't have this > > > > problem.) > > > > > > > > Anne > > > > > > > > > > > > On 6/15/05, Feng Xie (fxie) <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Pat: > > > > > > > > > > Too bad to hear that. Don't give up. > > > > > > > > > > In my case ( Axis + Tomcat 5 ), the soapAction is > > > > always > > "" in WSDL. What I > > > > > did is come up a very basic Java interface and let > > Java2WSDL to generate a > > > > > base WSDL. I then enhance the WSDL. I noticed that the > > soapAction is "" in > > > > > the based WSDL created by Java2WSDL. > > > > > > > > > > However, the soapAction in your WSDL is not "". Not > > > > sure > > whether that will > > > > > affect the dispatch process. > > > > > > > > > > Feng > > > > > > > > > > > > > > > > > > > > > ________________________________________________________________ > > > > __ > > > > __ > > > > __ > > > > This email has been scanned by the MessageLabs Email Security > > System. > > > > For more information please visit > > > > http://www.messagelabs.com/email > > > > > > ____________________________________________________________________ > > __ > > > > > > > > > > > ____________________________________________________________________ > > __ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________