Hi Vinh, answers below: > 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.
Right, it would only cause problems in code generation. The way the codegen works, is it looks at the namespace URI to determine the Capability URI. The built-in capabilities (ie the ones from the specifications) don't have any way of deducing the URI from the WSDL so we have a big lookup table that handles the standard ones. > > 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. Yes, but again it has to look at the input message since the WSDL puts its operations into one namespace, the targetNamespace for the WSDL. > > 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? Not sure I understand this. Resources don't have a namespace? Unless you're talking about the WSDL namespace. This would be enforced at the operation message message (schema element) 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. I don't think this is true. Each capability deals with operations from one of those. Resources can aggregate them. I must be missing something here. The resolution would know which resource it is dealing with because of the request URI. So at that point it would be looking at the resource's capabilities and trying to find the right method. If the capability had two methods whose java names were fooOperation, but which belonged to two different capabilities, finding the right operation would be just a matter of taking the incoming soap body element's namespace URI, looking it up to see if it is built in, and if not then looking up to see see if there's a capability that has this URI. Let me know if I've missed something. I'm very much interested in your concern about scalability. > > 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] > Thanks, Andrew Andrew Eberbach Autonomic Computing (919) 254-2645 T/L: 444-2645 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
