I was hoping that someone will answer my queries. But since i didnt get any reply yet, I did some more digging and I see that from the "Re: [Axis2] Problem with endpoint in wsdl" thread, that there is a bug in Axis2 1.1.1 with respect to the soap address being different for Soap 11 and Soap 12 protocols. Is this correct? Is there a fix for this already?
Can someone please let me know as to how i can overcome the issues i'm facing. Thanks, vedha On Mon, 2007-01-29 at 17:16 -0800, Vedha Vijayan wrote: > Hi, > > I have few questions regarding the service end point in a wsdl: (I'm > using Axis2 1.1.1 version) > > My initial endpoint for UserService was > http://localhost:8080/Comergent/services/UserService, and things worked > fine. I have Axis2 installed as an embedded webapp. I wanted my service > endpoint to point to > http://localhost:8080/Comergent/ws/matrix/services/UserService instead. > My wsdl is updated to reflect this change. I have a custom wsdl that is > part of the UserService.aar file and the services.xml has the > 'useOriginalwsdl' property set. On the browser when i point to > http://localhost:8080/Comergent/ws/matrix/services/UserService?wsdl the > wsdl obtained is different from the custom wsdl. The auto-generated wsdl > has two bindings one for Soap11 and another for Soap12. The Soap11 > binding for some reason points to my initial endpoint > ( http://localhost:8080/Comergent/services/UserService ), but the Soap12 > binding has the newer end point. > > 1. Although the custom wsdl has both bindings pointing to the newer > URL, why does the auto-generated wsdl use different binding for > Soap11? And why doesnt the 'useOriginalwsdl' property though set > to true, not work in my case? > 2. Are there any changes to be made on the server side in-order to > map the updated URL to service archive file? (Other than the > necessary modifications to web.xml to include the > servlet-mapping for updated URL) > > > The client stub has the following line to set the appropriate Soap > version; > > > _serviceClient.getOptions().setSoapVersionURI(org.apache.axiom.soap.SOAP12Constants.SOAP_ENVELOPE_NAMESPACE_URI); > > > Even then, when i run my client with the newer endpoint, I hit the > following problem; > > org.apache.axis2.AxisFault: Service not found operation terminated !! > [java] at > org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:271) > [java] at > org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:202) > > > I have setup SOAPMonitor on the server side and I dont see any request > coming in at all. This leads me to believe that the in pre-dispatch > phase none of the dispatchers are able to locate the operation within > the service. > > However, when the client is run with the older endpoint, the server is > still able to honor the request and send back the response. This > behavior leads to another set of questions I have: > > 3. What information is used by the dispatchers to verify the existence > of an operation within a service? > > 4. I have a scenario, where in the service endpoint is determined at > runtime based on location of the incoming request. Given this scenario, > how does one map the service class to multiple end points. The wsdl > location is generated at runtime and the client then invokes the > operation defined within the service. On the server-side, how do we > handle this in terms of verifying the service location? > > > Thanks in advance. > > vedha > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Vedha Vijayan Senior Software Engineer Comergent Technologies Inc. Ph: 650 232 5833 Fax: 650 232 6010 Email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
