Hi Andrew, Yep, I always wondered what the capability URI should be because so far, I can put any arbitrary value there and it wouldn't always cause problems. Since Muse first looks at the java method signatures in all the capabilities to see if any of them matches the wsdl operation input, it seems to ignore the URI entirely.
So now, if the new update does look at the URI, it just might resolve the problem where different namespaces may have the same operation name. But we have one major issue: There is no rule yet on what the capability URI should represent. So far, it has not been enforced to associate only with the operation message namespace. In many cases, it has been associated with the entire wsdl namespace, so a group of operations can be implemented by one capability. Now, if the we start mapping URIs to capabilities, do we enforce the namespace to be at the operation message level, or the resource level? If the former, then the limitation is one capability per operation, which may not scale. If the latter, then the limitation is one URI per capability. This might be ok, but it breaks the current architecture where a single capability class can address operations from WS-N, WS-RF, etc. So from what it seems, it might all come out to 3 general approaches: 1) Configuration-based, where muse.xml provides configurations to map operations to capabilities. But then this goes back to the JAX-RPC approach Dan brought up. 2) Each capability can have a method that returns the URIs that it can address. But, are the URIs at the operation message level, or the resource level? If the resource level, what happens if multiple capabilities can address the same URI (i.e. operations in one wsdl are separated into multiple capabilities)? 3) Push it to the design level where wsdl operation names must follow a certain naming convention in order for Muse to support the wsdl. -----Original Message----- From: Andrew Eberbach [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 12:51 PM To: [email protected] Subject: Re: Operation name collision Hi I included that link more for my reference than for yours (for obvious reasons). As for your issue, as far as I understand it is the same as what Vinh brought up https://issues.apache.org/jira/browse/MUSE-214#action_12482863 along with the discussion following it. The resolution of the problem would cover two approaches. First, it would move the determination of the method name out to the WSDL operation name. The second would be to include the namespace URI when doing the runtime resolution of the name which would cover WSDL operations that have the same name but live in different capabilities. The only trick there being that the capability URI of the operation would be taken from the input element (since the WSDL operation would technically live in the WSDL targetNamespace). Thanks, Andrew Andrew Eberbach Autonomic Computing (919) 254-2645 T/L: 444-2645 [EMAIL PROTECTED] "José Antonio Sánchez" <[EMAIL PROTECTED]> 03/22/2007 03:10 PM Please respond to [email protected] To [email protected] cc Subject Re: Operation name collision I reported the bug so I'm following the discussion but I thought this was not related to this issue since the operation name (completed) is correct, it was not the case of cannot-compensate-fault element that generated an invalid operation name. As the method is duplicated, I would have expected an error saying that http://www.webservicestransactions.org/schemas/wstxm/tx-lra/2003/03/completed maps to multiple operations but instead I get an error saying that it cannot find an implementation for that method although it has two of them to choose from. Also, in case of doubt I've implemented a CompensatorCompleted method and it cannot find it too so I don't know if there's a problem with me not following some convention or if this is a limitation of Muse working model. On 3/22/07, Andrew Eberbach <[EMAIL PROTECTED]> wrote: > Hi, > > You are the second person to bring this up this week :) This will be one > of the first fixes in 2.3. See: > https://issues.apache.org/jira/browse/MUSE-214 > > Thanks, > Andrew > > Andrew Eberbach > Autonomic Computing > (919) 254-2645 > T/L: 444-2645 > [EMAIL PROTECTED] > > > > "José Antonio Sánchez" <[EMAIL PROTECTED]> > 03/22/2007 02:06 PM > Please respond to > [email protected] > > > To > [email protected] > cc > > Subject > Operation name collision > > > > > > > Hello, I'm having the following problem. In my service I have to > implement two interfaces and they have an operation named the same but > messages from every operation are in different namespaces. I've solved > it in the wsdl with the following: > > <wsdl:message name="CompletedMessage"> > <wsdl:part element="wsctx:completed" name="content"/> > </wsdl:message> > ............................. > <wsdl:operation name="completed"> > <wsdl:input > wsa:Action=" > http://docs.oasis-open.org/schemas/2005/10/wsctx/completed"; > message="tns:CompletedMessage"/> > </wsdl:operation> > > and > > > <wsdl:message name="CompensatorCompletedMessage"> > <wsdl:part name="content" element="lra:completed"/> > </wsdl:message> > ........................... > <wsdl:operation name="CompensatorCompleted"> > <wsdl:input > wsa:Action=" > http://www.webservicestransactions.org/schemas/wstxm/tx-lra/2003/03/completed > " > message="tns:CompensatorCompletedMessage"/> > </wsdl:operation> > > WSDL2Java has generated two capabilities and every one of them has a > complete() method. > Now when I try to invoke my resouce I get: > > java.lang.RuntimeException: [ID = 'MissingOperationImplementations'] > The WSDL file '/wsdl//Installation.wsdl' has the following operations > which have no match in any of the resource's capabilities: > [http://www.webservicestransactions.org/schemas/wstxm/tx-lra/2003/03/completed] > at > org.apache.muse.core.descriptor.SimpleResourceDescriptor.createCapabilityDefinitions(SimpleResourceDescriptor.java:138) > at > org.apache.muse.core.descriptor.SimpleResourceDescriptor.load(SimpleResourceDescriptor.java:397) > at > org.apache.muse.core.descriptor.SimpleDeploymentDescriptor.createResourceDefinitions(SimpleDeploymentDescriptor.java:74) > at > org.apache.muse.core.descriptor.SimpleDeploymentDescriptor.load(SimpleDeploymentDescriptor.java:173) > at > org.apache.muse.core.platform.AbstractIsolationLayer.initialize(AbstractIsolationLayer.java:144) > at > org.apache.muse.core.platform.axis2.AxisIsolationLayer.handleRequest(AxisIsolationLayer.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.axis2.receivers.RawXMLINOutMessageReceiver.invokeBusinessLogic(RawXMLINOutMessageReceiver.java:88) > at > org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMessageReceiver.java:39) > at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493) > at > org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:319) > at > org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:247) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:216) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) > at java.lang.Thread.run(Thread.java:595) > > Also I had problem with some operations that did not have the same > name as its messages but they seem to be passing once I created > methods for them in my capability with the operation name instead of > the message element name but this doesn't work for complete. Although > I've created a CompensatorCompleted() method in my capability it keeps > complaining. What's the convention Muse uses to route a message to a > capability and a particular method? How can I change my > wsdl/capability to get it working? I can modify the wsdl but not the > xsd files that defines lra:completed and wsctx:completed elements. > > -- > Saludos. > José Antonio Sánchez > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Saludos. José Antonio Sánchez --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
