[LDAP DAS] 1.0.0 Just about Done + Question
Howdy, UPDATE: The LDAP DAS is reading and writing graphs and it can process the change summary. I still have a few more tests to write, but I think it's pretty solid. QUESTION: Right now I default the isTypeSystemCreated configuration parameters (Keyed by model namespaceURI) to false. If the DAS runs with it set this way, it will always attempt to create the LDAP type system, but will still check to see if it exists first. I'd like to automate setting it to true, after the DAS has run for the first time. One way would be to just rewrite the configuration file, and then read it again in order to validate the rewrite. Does this sound OK? Are there better ways? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [LDAP DAS] 1.0.0 Just about Done + Question
Very good to hear these news Ole. Regarding your question, does create the LDAP type system means creating the LDAP schema on the LDAP server ? Do you also have the scenario of updating the schema ? What about pre-populating like in sample applications ? Well, if you have these scenarios, maybe it would be better to use an utility to allow applications to do that, we have a similar thing in RDB DAS (dbConfig). As for the other option, that you mentioned, are you always going to have access to the configFile ? In the case of RDB DAS, we allow for configuring only by passing a Stream, and in this case I guess you solution would fail. On 7/21/07, Ole Ersoy [EMAIL PROTECTED] wrote: Howdy, UPDATE: The LDAP DAS is reading and writing graphs and it can process the change summary. I still have a few more tests to write, but I think it's pretty solid. QUESTION: Right now I default the isTypeSystemCreated configuration parameters (Keyed by model namespaceURI) to false. If the DAS runs with it set this way, it will always attempt to create the LDAP type system, but will still check to see if it exists first. I'd like to automate setting it to true, after the DAS has run for the first time. One way would be to just rewrite the configuration file, and then read it again in order to validate the rewrite. Does this sound OK? Are there better ways? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question on callback bindings
Raymond Feng wrote: Hi, Simon. Multiple references can be wired to the same service. To support the callback, we need to know which component reference the call is from. The information is probably in the context of the invocation. We can create a fixed wire from $callback$.s1 to $callback$.r1. Then we need to know all the references that are wired to this service. I'm wondering if we can use the $callback$.s1 more dynamically by binding the caller as the callback target on the fly? I think either of these approaches is possible. My current code takes the first approach for wired local calls using binding.sca, and the second approach for unwired calls across the Web Service binding, with the dynamic addressing information being passed using WS-Addressing headers. For a local call, we could put this information in a thread-local context. Simon Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, July 20, 2007 11:36 AM Subject: Re: Question on callback bindings On 7/20/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, It seems that we all agree the callback path should be treated as a regular interaction using the callback interface over the selected binding. Can we then simplify the callback processing in Tuscany as follows? 1) Normalize the callbacks as a regular reverse call in the CompositeBuilderImpl: a) Create an internal service for the callback of a reference on the source component. reference name=r1 interface.wsdl interface=http://ns1#wsdl.interface(Service1) callbackInterface=http://ns1#wsdl.interface(Service1Callback)/ binding.ws .../ callback binding.ws .../ /callback /reference service name=$callback$.r1 interface.wsdl interface=http://ns1#wsdl.interface(Service1Callback)/ binding.ws .../ !-- copied from the binding.ws under callback -- /service 2) Create an internal reference for the callback of a service on the target component service name=s1 interface.wsdl interface=http://ns1#wsdl.interface(Service1) callbackInterface=http://ns1#wsdl.interface(Service1Callback)/ binding.ws .../ callback binding.ws .../ /callback /service reference name=$callback$.s1 interface.wsdl interface=http://ns1#wsdl.interface(Service1Callback)/ binding.ws .../ !-- copied from the binding.ws under callback -- /reference This speical reference will be bound to the caller component in the context. 2) Remove all the speical handling of callbacks in core, including the callback invocation chains, callback wires and callback invoker since now the callback is just a regular invocation. Does it make sense? Thanks, Raymond - Original Message - From: Mike Edwards [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, July 20, 2007 4:27 AM Subject: Re: Question on callback bindings Simon Nash wrote: I am implementing approach 1). The code is turning out to be straightforward and this approach fully supports the SCA callback spec AIUI. The Axis2 callback MEP isn't the same as an SCA callback, and it's confusing that these have the same name. With the Axis2 callback MEP, the forward call is sent asynchronously, and the callback message carries the result from the forward call. In SCA, the callback is a normal call made in the reverse direction, and the signature of the callback is unrelated to the signature of the forward call. Simon Folks, This is the correct interpretation. SCA callback is very general and make no assumption about the nature of the transport used between the reference and the service. The call interface has each method able to be a full request/response, if that is what is required. They can of course have a void return or be a OneWay invocation. The callback interface equally allows each method to be a full request/response or a OneWay. There is no assumption made about the number or the timing of the invocations on the callback interface related to a given invocation on the call interface. Indeed, SCA today has no metadata that captures these relationships (it has been suggested quite seriously that it might be possible to capture this metadata as an abstract BPEL process, but this has not been progressed as a formal addition to the Assembly specification). So, the correct behaviour is for the call to be treated as a regular SOAP/HTTP interaction, completely independent from any callback interaction. A given call may result in 0, 1 or many callback invocations. A simple example might be a service for placing an order. The place order operation may be request/response with the response acting as a ack that the order was received. However, the place order may then be followed by callbacks like the following: - order accepted - once credit checking and item availability checks are done - order dispatched - once the order items have been packaged and
Re: Problem with new callback implementation for the Web Service binding
I'm glad to see my post about this made it to the ML. I have not received a copy back yet myself from the server. I had thought about this approach and I think it may be the best solution. One possible point against it is that there could be some bindings that are able to support a suitable callback MEP themselves in a more efficient way than having completely separate forward and callback paths. Having these bindings be callback aware and able to control the callback interactions would be better than having the core create two independent one-way bindings that don't know about each other. There's also the question of how the forward and reverse bindings and forward calls and callbacks are correlated. At present there is code in the bindings to perform this correlation, in a binding-specific way. If we move this code to the core, we will need to be sure that the approach we come up with is suitable for all binding types and all possible endpoints. On the plus side, this approach would make both the core and the bindings a lot simpler and I am inclined to think that on balance it will be worth making these changes. I would like to stage this by first completing the implementation that I currently have, which is functionally equivalent to what you are suggesting. The new code for this in the Web Service binding looks more complicated than it is because the code is currently dual-pathed to support both the current tactical solution and the new approach. When I remove the dual-pathing and the massive code duplication, you will see that it is already very close to what you suggest. Now let's come back to the problem that I cam currently seeing. I'm not sure if you have looked into the details of the failure. My code is effectively already doing exactly what you suggest (including registering a servlet mapping for the pseudo-service that supports the callback reference), and I am seeing a servlet unavailable message when trying to invoke the servlet. I'd like to understand why this is happening before making all the code change you are suggesting, which could possibly still result in the same error because they will be doing the same thing. If anyone else understands how servlet registration and servlet mapping works and could help me today to look into this problem, I would appreciate it. Otherwise I will continue to educate myself in this area and try some other scenarios to attempt to narrow it down. The first thing I will try is doing exactly what Raymond suggests, but manually in the SCDL, to see whether the problem still occurs. Simon Raymond Feng wrote: Hi, Simon. I think the problem is that we need to create an internal callback service to listen on the callbacks from the web service protocol. Please see my proposal [1]. If we do so, a servlet mapping MyClientComponent/$callback$.myService for this special service will be registered when it is activated. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20497.html Thanks, Raymond - Original Message - From: Simon Nash [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Saturday, July 21, 2007 5:54 PM Subject: Problem with new callback implementation for the Web Service binding I have come across a problem with my new implementation of callbacks across the Web Service binding. This code handles callbacks in the same way as forward calls by creating an Axis service and a servlet on the reference end to receive the callbacks, and using a normal Axis2 OperationClient on the service end to invoke them. The problem is an error org.apache.axis2.AxisFault: Transport error: 404 Error: Servlet /MyClientComponent/$callback$.myService is not available when the service side attempts to make a callback to the client side. This URI is one I have constructed to represent a reference callback endpoint. I have created a servlet and registered a mapping for this callback URI using the same code that does this successfully for a service. I don't know why my callback servlet isn't available but my servlet for the forward call works OK. In the following trace there are some debug println calls showing that the servlet mapping is being registered with the correct URI, and that the server callback invocation back to the client is using the same URI that was extracted from WS-Addressing information sent on the forward call. To run the new code path and see this problem, you need my latest patch (patch2) applied, and you also need to make some small modifications to the code in binding-ws-axis2 and to the SCDL and WSDL files in simple-callback-ws. 1. In Axis2ReferenceBindingProvider.java and Axis2ServiceBindingProvider.java, change the value of tactical from true to false, then rebuild the binding-ws-axis2 module. 2. In simple-callback-ws, change the WSDL to use a one-way MEP rather than a two-way MEP for the call to someMethod (see commented instructions). Also change the SCDL
[jira] Created: (TUSCANY-1474) Unable to create two SCA services that use the Web Service binding
Unable to create two SCA services that use the Web Service binding -- Key: TUSCANY-1474 URL: https://issues.apache.org/jira/browse/TUSCANY-1474 Project: Tuscany Issue Type: Bug Components: Java SCA Tomcat Integration Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Priority: Blocker Fix For: Java-SCA-Next As part of debugging the servlet is not available problem (see [1]), I converted simple-callback-ws to use matched pairs of services and references instead of callbacks, and I got exactly the same error. It seesms that no more than one Tomcat Axis2 servlet can be registered, which means that it's not possible to have more than one SCA service that uses the Web Service binding. This is a blocking defect for my work to support callbacks across the Web Service binding. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20548.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1474) Unable to create two SCA services that use the Web Service binding
[ https://issues.apache.org/jira/browse/TUSCANY-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-1474: Attachment: simple-callback2-ws.zip This test case illustrates the servlet problem in a non-callback scenario. Unable to create two SCA services that use the Web Service binding -- Key: TUSCANY-1474 URL: https://issues.apache.org/jira/browse/TUSCANY-1474 Project: Tuscany Issue Type: Bug Components: Java SCA Tomcat Integration Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Priority: Blocker Fix For: Java-SCA-Next Attachments: simple-callback2-ws.zip As part of debugging the servlet is not available problem (see [1]), I converted simple-callback-ws to use matched pairs of services and references instead of callbacks, and I got exactly the same error. It seesms that no more than one Tomcat Axis2 servlet can be registered, which means that it's not possible to have more than one SCA service that uses the Web Service binding. This is a blocking defect for my work to support callbacks across the Web Service binding. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20548.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1474) Unable to create two SCA services that use the Web Service binding
[ https://issues.apache.org/jira/browse/TUSCANY-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514463 ] Simon Nash commented on TUSCANY-1474: - Here's the error that I am seeing: Running simplecallback.SimpleCallbackTestCase log4j:WARN No appenders could be found for logger (org.apache.axiom.om.util.StAXUtils). log4j:WARN Please initialize the log4j system properly. 22-Jul-2007 11:05:08 org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 22-Jul-2007 11:05:08 org.apache.catalina.startup.ContextConfig defaultWebConfig INFO: No default web.xml 22-Jul-2007 11:05:08 org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/jsp/resources/jsp_2_0.xsd 22-Jul-2007 11:05:08 org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/jsp/resources/web-jsptaglibrary_1_1.dtd 22-Jul-2007 11:05:08 org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/jsp/resources/web-jsptaglibrary_1_2.dtd 22-Jul-2007 11:05:08 org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/jsp/resources/web-jsptaglibrary_2_0.xsd 22-Jul-2007 11:05:08 org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/resources/j2ee_web_services_1_1.xsd 22-Jul-2007 11:05:08 org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8085 22-Jul-2007 11:05:08 org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8085 Main thread Thread[main,5,main] aClientMethod on thread Thread[main,5,main] aClientMethod return from someMethod on thread Thread[main,5,main] Sleeping ... 22-Jul-2007 11:05:09 org.apache.catalina.core.StandardWrapper unload INFO: Waiting for 1 instance(s) to be deallocated setMyServiceCallback on thread Thread[pool-1-thread-1,5,main] someMethod on thread Thread[pool-1-thread-1,5,main] 22-Jul-2007 11:05:09 org.apache.catalina.core.StandardWrapperValve invoke INFO: Servlet /MyClientComponent/MyServiceCallback is currently unavailable RuntimeException invoking receiveResult: java.lang.reflect.UndeclaredThrowableException java.lang.reflect.UndeclaredThrowableException at $Proxy10.receiveResult(Unknown Source) at simplecallback.MyServiceImpl.someMethod(MyServiceImpl.java:48) 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.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.PassByValueInvoker.invoke(PassByValueInvoker.java:61) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInteceptor.invoke(DataTransformationInteceptor.java:68) at org.apache.tuscany.sca.binding.axis2.Axis2ServiceBindingProvider.invokeTarget(Axis2ServiceBindingProvider.java:505) at org.apache.tuscany.sca.binding.axis2.Axis2ServiceInMessageReceiver.invokeBusinessLogic(Axis2ServiceInMessageReceiver.java:62) at org.apache.axis2.receivers.AbstractInMessageReceiver.receive(AbstractInMessageReceiver.java:33) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:144) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:279) at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:116) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at org.apache.tuscany.sca.binding.axis2.Axis2ServiceServlet.service(Axis2ServiceServlet.java:234) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) 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
[jira] Updated: (TUSCANY-1474) Unable to create two SCA services that use the Web Service binding
[ https://issues.apache.org/jira/browse/TUSCANY-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-1474: Attachment: (was: simple-callback2-ws.zip) Unable to create two SCA services that use the Web Service binding -- Key: TUSCANY-1474 URL: https://issues.apache.org/jira/browse/TUSCANY-1474 Project: Tuscany Issue Type: Bug Components: Java SCA Tomcat Integration Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Priority: Blocker Fix For: Java-SCA-Next As part of debugging the servlet is not available problem (see [1]), I converted simple-callback-ws to use matched pairs of services and references instead of callbacks, and I got exactly the same error. It seesms that no more than one Tomcat Axis2 servlet can be registered, which means that it's not possible to have more than one SCA service that uses the Web Service binding. This is a blocking defect for my work to support callbacks across the Web Service binding. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20548.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1474) Unable to create two SCA services that use the Web Service binding
[ https://issues.apache.org/jira/browse/TUSCANY-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-1474: Attachment: simple-callback2-ws.zip Here's a test case that shows the problem (second attempt, as the first had a typo in the WSDL). Unable to create two SCA services that use the Web Service binding -- Key: TUSCANY-1474 URL: https://issues.apache.org/jira/browse/TUSCANY-1474 Project: Tuscany Issue Type: Bug Components: Java SCA Tomcat Integration Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Priority: Blocker Fix For: Java-SCA-Next Attachments: simple-callback2-ws.zip As part of debugging the servlet is not available problem (see [1]), I converted simple-callback-ws to use matched pairs of services and references instead of callbacks, and I got exactly the same error. It seesms that no more than one Tomcat Axis2 servlet can be registered, which means that it's not possible to have more than one SCA service that uses the Web Service binding. This is a blocking defect for my work to support callbacks across the Web Service binding. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20548.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with new callback implementation for the Web Service binding
Simon Nash wrote: (cut) Now let's come back to the problem that I cam currently seeing. I'm not sure if you have looked into the details of the failure. My code is effectively already doing exactly what you suggest (including registering a servlet mapping for the pseudo-service that supports the callback reference), and I am seeing a servlet unavailable message when trying to invoke the servlet. I'd like to understand why this is happening before making all the code change you are suggesting, which could possibly still result in the same error because they will be doing the same thing. If anyone else understands how servlet registration and servlet mapping works and could help me today to look into this problem, I would appreciate it. Otherwise I will continue to educate myself in this area and try some other scenarios to attempt to narrow it down. The first thing I will try is doing exactly what Raymond suggests, but manually in the SCDL, to see whether the problem still occurs. I tried this and got exactly the same error with not a callback in sight anywhere, just plain old references and services making forward calls. I have created TUSCANY-1474 for this problem and I have attached my test case simple-callback2-ws.zip to it. It seesms that no more than one Tomcat Axis2 servlet can be registered, which means that it's not possible to have more than one SCA service that uses the Web Service binding. Simon Raymond Feng wrote: Hi, Simon. I think the problem is that we need to create an internal callback service to listen on the callbacks from the web service protocol. Please see my proposal [1]. If we do so, a servlet mapping MyClientComponent/$callback$.myService for this special service will be registered when it is activated. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20497.html Thanks, Raymond - Original Message - From: Simon Nash [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Saturday, July 21, 2007 5:54 PM Subject: Problem with new callback implementation for the Web Service binding I have come across a problem with my new implementation of callbacks across the Web Service binding. This code handles callbacks in the same way as forward calls by creating an Axis service and a servlet on the reference end to receive the callbacks, and using a normal Axis2 OperationClient on the service end to invoke them. The problem is an error org.apache.axis2.AxisFault: Transport error: 404 Error: Servlet /MyClientComponent/$callback$.myService is not available when the service side attempts to make a callback to the client side. This URI is one I have constructed to represent a reference callback endpoint. I have created a servlet and registered a mapping for this callback URI using the same code that does this successfully for a service. I don't know why my callback servlet isn't available but my servlet for the forward call works OK. In the following trace there are some debug println calls showing that the servlet mapping is being registered with the correct URI, and that the server callback invocation back to the client is using the same URI that was extracted from WS-Addressing information sent on the forward call. To run the new code path and see this problem, you need my latest patch (patch2) applied, and you also need to make some small modifications to the code in binding-ws-axis2 and to the SCDL and WSDL files in simple-callback-ws. 1. In Axis2ReferenceBindingProvider.java and Axis2ServiceBindingProvider.java, change the value of tactical from true to false, then rebuild the binding-ws-axis2 module. 2. In simple-callback-ws, change the WSDL to use a one-way MEP rather than a two-way MEP for the call to someMethod (see commented instructions). Also change the SCDL to specify a wsdl.port instead of a wsdl.binding for the callback (see commented instructions). Rebuild simple-callback-ws and you should see the following trace. Any suggestions for what is causing this problem would be very gratefully received! Simon Running simplecallback.SimpleCallbackTestCase log4j:WARN No appenders could be found for logger (org.apache.axiom.om.util.StAXUtils). log4j:WARN Please initialize the log4j system properly. Axis2ServiceProvider: adding servlet mapping for http://localhost:8085/MyClientComponent/$callback$.myService (cut) ... 47 more RuntimeException invoking receiveResult: java.lang.reflect.UndeclaredThrowableException 22-Jul-2007 00:31:28 org.apache.coyote.http11.Http11Protocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8085 Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.265 sec FAILURE! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1473) Define component's service with interface.wsdl ,throws 'No matching operation' error.
[ https://issues.apache.org/jira/browse/TUSCANY-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514469 ] wangfeng commented on TUSCANY-1473: --- Thank Raymond for providing the patch. I think this resolution is not perfect. I read the code and found this getPhysical method always returned 'Object' class type.We called the isAssignableFrom method to match the input type,thus what ever type was inputed,this method always returned true. Maybe modifing the getPhysical method's return type which should be the type defined in the WSDL file would be better. Define component's service with interface.wsdl ,throws 'No matching operation' error. - Key: TUSCANY-1473 URL: https://issues.apache.org/jira/browse/TUSCANY-1473 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-0.91 Environment: Windows XP Reporter: wangfeng Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: testcase.zip I define the component's service with interface.java,the sample runs fine. but when I modify the component's service with interface.wsdl,the sample throws an exception. The throwable stack is : Exception in thread main java.lang.IllegalArgumentException: No matching operation is found: public abstract java.lang.String helloworld.HelloWorldService.getGreetings(java.lang.String) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:69) at $Proxy10.getGreetings(Unknown Source) at helloworld.HelloWorldClient.main(HelloWorldClient.java:33) I look into the code,found the invoke mothod's input type is 'String',but the method which name is operation.getInputType().getLogical().get(i).getPhysical() on the SourceOperation of the InvocationChain is always return 'Object' type,so can't find an operation to match. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (TUSCANY-1473) Define component's service with interface.wsdl ,throws 'No matching operation' error.
[ https://issues.apache.org/jira/browse/TUSCANY-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] wangfeng reopened TUSCANY-1473: --- Thank Raymond for providing the patch. I think this resolution is not perfect. I read the code and found this getPhysical method always returned 'Object' class type.We called the isAssignableFrom method to match the input type,thus what ever type was inputed,this method always returned true. Maybe modifing the getPhysical method's return type which should be the type defined in the WSDL file would be better. Define component's service with interface.wsdl ,throws 'No matching operation' error. - Key: TUSCANY-1473 URL: https://issues.apache.org/jira/browse/TUSCANY-1473 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-0.91 Environment: Windows XP Reporter: wangfeng Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: testcase.zip I define the component's service with interface.java,the sample runs fine. but when I modify the component's service with interface.wsdl,the sample throws an exception. The throwable stack is : Exception in thread main java.lang.IllegalArgumentException: No matching operation is found: public abstract java.lang.String helloworld.HelloWorldService.getGreetings(java.lang.String) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:69) at $Proxy10.getGreetings(Unknown Source) at helloworld.HelloWorldClient.main(HelloWorldClient.java:33) I look into the code,found the invoke mothod's input type is 'String',but the method which name is operation.getInputType().getLogical().get(i).getPhysical() on the SourceOperation of the InvocationChain is always return 'Object' type,so can't find an operation to match. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1473) Define component's service with interface.wsdl ,throws 'No matching operation' error.
[ https://issues.apache.org/jira/browse/TUSCANY-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] wangfeng updated TUSCANY-1473: -- Comment: was deleted Define component's service with interface.wsdl ,throws 'No matching operation' error. - Key: TUSCANY-1473 URL: https://issues.apache.org/jira/browse/TUSCANY-1473 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-0.91 Environment: Windows XP Reporter: wangfeng Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: testcase.zip I define the component's service with interface.java,the sample runs fine. but when I modify the component's service with interface.wsdl,the sample throws an exception. The throwable stack is : Exception in thread main java.lang.IllegalArgumentException: No matching operation is found: public abstract java.lang.String helloworld.HelloWorldService.getGreetings(java.lang.String) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:69) at $Proxy10.getGreetings(Unknown Source) at helloworld.HelloWorldClient.main(HelloWorldClient.java:33) I look into the code,found the invoke mothod's input type is 'String',but the method which name is operation.getInputType().getLogical().get(i).getPhysical() on the SourceOperation of the InvocationChain is always return 'Object' type,so can't find an operation to match. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Conversational - spec question
Hi guys, See below Dave - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, July 20, 2007 1:59 PM Subject: Re: Conversational - spec question Simon Laws wrote: On 7/20/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, It is clear from reading other sections of the specification that it is intended that @ConversationID is used in implementation classes other than those of CONVERSATION scope. Further down in 1.2.51 of the JavaComponentImplementation spec, it says the following: 1. The implementation can be built as a stateless piece of code (essentially, the code expects a new instance of the code to be used for each method invocation). The code must then be responsible for accessing the conversationID of the conversation, which is maintained by the SCA runtime code. The implementation is then responsible for persisting any necessary state data during the processing of a method and for accessing the persisted state data when required, all using the conversationID as a key. This is clear that stateless (ie NOT CONVERSATION scope) implementations can use the conversationID. So I think that @ConversationID is always actioned - the only difference is how often it gets actioned (a CONVERSATION scoped implementation gets it just the once, while every invocation of a stateless will require injection). Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks Mike So if I understand correctly: - a stateless-scoped component is injected with the conversation id when the request is presented to it - a composite-scoped component is injected with the conversation id when the request is presented to it - a conversation-scoped component is injected once with the conversation id when it's created (I see this as an optimization) I was assuming that we were not going to present concurrent requests to a composite-scoped component (we should serialize them), so it shouldn't be a problem? However, I couldn't find a statement in the spec about serialization of concurrent requests targeting composite-scoped components. Can a composite-scoped component be presented with concurrent requests? Composite scoped components can have concurrent requests inflight, the runtime does not need to serialize for concurrency. I recall having this conversation during the spec work, but cant find verbiage in the specs. FWIW, I recall that for composite scoped components, we decided that it was not possible to inject @ConversationID nor callback references, AND therefore the component implementation would have to use the appropriate API which would return the correct info in the context of the request. -- Jean-Sebastien - 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]
Re: Conversational - spec question
Hi,
I've been disconnected from the network for the last two days. Sorry
for jumping in late.
I don't like the idea of using threadLocals for this because it creates
undesirable thread affinities. More complex scenarios involving
intervening async calls will result in the need to propagate this context to
other threads. See my previous post. I really rather go that way,
esp. since I think that is the spec group's intention.
Dave
- Original Message -
From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Saturday, July 21, 2007 7:07 PM
Subject: Re: Conversational - spec question
Sorry for the delay in responding. I have been very preoccupied with
debugging the new Web Service callback implementation. I believe there
is good news on this - see below.
Simon
ant elder wrote:
On 7/21/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
ant elder wrote:
On 7/21/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
ant elder wrote:
On 7/20/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
snip
- I have to deal with concurrent requests in my business logic, but
then
I'm having a hard time understanding how my business logic is
going to
handle interlaced injection calls and business method calls in a
multi-threaded environment...
Could you explain this issue a bit more, what do you mean
interlaced
injection calls and business method calls?
...ant
My component implementation looks like this:
class MyBrokenComponent {
Client callback;
@Callback
void setCallback(Client callback) {
this.callback = callback;
}
void echo(String s) {
callback.echoCallback(s);
}
2 concurrent requests enter a composite scoped component instance (a
single instance). I'm not feeling lucky today and it happens that my
fast Dual core processor just decided to schedule the execution of
the
requests as follows:
Thread 1
component.setCallback(callback A corresponding to the request in
Thread
1)
Thread 2
component.setCallback(callback 2 corresponding to the request in
Thread
2)
Thread 1
echo(hey)
Thread 2
echo(hey)
Both callbacks will go to back A. Not good :) and by the way, do I
need
to mark my setter methods synchronized???
I think my callback implementation handles this correctly. The injected
callback does not hold the callback destination statefully (giving the
side benefit that this injection could be optimized to only happen once).
When the request arrives on the server thread, the return addressing
information is placed in the thread-local message context (the code
handles
both remote and local callbacks). When the injected callback is invoked,
it uses the information in the thread-local message context to determine
where the callback should be routed.
I guess we can play similar scenarios and illustrate the same issues
with ConversationID, Callbacks, or RequestContext. How can this
work at
all?
Right, which is why back here [1] the suggestion was throwing some
exception
when its composite scoped. Can't we do that and just say conversations
aren't supported in this configuration?
...ant
[1]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200707.mbox/[EMAIL
PROTECTED]
Yes, we could throw an exception at assembly/startup time, or even
simpler... I'm not sure we need to write any code to handle this at this
point, we could just make clear here on the list that some
configurations are not supported and that the behavior is undefined
until clarified with the spec for:
- injection of thread-specific information (requestContext, callback)
into component instances shared across threads (scopes other than
stateless).
- injection of conversation-specific information (conversationID,
conversationAttributes) into component instances shared across
conversations (scopes other than conversational and stateless)
Thoughts?
Sounds good to me. I shall go write no code for it :)
...ant
-
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]
XSDDocumentProcessor visibility
Looks like XSDDocumentProcessor is not being registered with the proper artifact extension point, and it's being only available internally to the WSDLDocumentProcessor. Should we register it with the extension point to make it more widely available ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [LDAP DAS] 1.0.0 Just about Done + Question
Hi Luciano, Luciano Resende wrote: Very good to hear these news Ole. Regarding your question, does create the LDAP type system means creating the LDAP schema on the LDAP server ? Yes Do you also have the scenario of updating the schema ? Yes as long as the Schema update is versioned using the xsd namespace, as in http://maven.apache.org/pom/3.0.0 vs. http://maven.apache.org/pom/4.0.0 What about pre-populating like in sample applications ? The tests populate, so for stress testing and so on it's just a matter of building on these. Well, if you have these scenarios, maybe it would be better to use an utility to allow applications to do that, we have a similar thing in RDB DAS (dbConfig). When I woke up this morning it occurred to me that I can just store the DAS's config in the LDAP Directory Information Tree (DIT LDAP Storage Structure). That's a typical LDAP usage scenario anyways. What we could do is on first startup, store the configuration in the DIT, then on subsequent starts the minimal connection information is read from the config file, and the rest comes from the DIT. When the user wants an updated configuration file, she just loads the configuration in the DIT and serializes it to XML. Sound OK? As for the other option, that you mentioned, are you always going to have access to the configFile? In the case of RDB DAS, we allow for configuring only by passing a Stream, and in this case I guess you solution would fail. I think this scenario would be covered by storing the configuration in the DIT. Thoughts? Thanks, - Ole SNIP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1474) Unable to create two SCA services that use the Web Service binding
[ https://issues.apache.org/jira/browse/TUSCANY-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514487 ] Raymond Feng commented on TUSCANY-1474: --- Hi, Simon. I just ran your test case with the the latest trunk code and it was successful without any errors both in Eclipse and maven. The sleep method may need a longer timout value in some cases. Thanks, Raymond Unable to create two SCA services that use the Web Service binding -- Key: TUSCANY-1474 URL: https://issues.apache.org/jira/browse/TUSCANY-1474 Project: Tuscany Issue Type: Bug Components: Java SCA Tomcat Integration Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Priority: Blocker Fix For: Java-SCA-Next Attachments: simple-callback2-ws.zip As part of debugging the servlet is not available problem (see [1]), I converted simple-callback-ws to use matched pairs of services and references instead of callbacks, and I got exactly the same error. It seesms that no more than one Tomcat Axis2 servlet can be registered, which means that it's not possible to have more than one SCA service that uses the Web Service binding. This is a blocking defect for my work to support callbacks across the Web Service binding. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20548.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSDDocumentProcessor visibility
+1. since I imagine xsd documents is not something that is only used with wsdls. - Venkat On 7/22/07, Luciano Resende [EMAIL PROTECTED] wrote: Looks like XSDDocumentProcessor is not being registered with the proper artifact extension point, and it's being only available internally to the WSDLDocumentProcessor. Should we register it with the extension point to make it more widely available ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - 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]
Re: Conversational - spec question
See inline. Simon scabooz wrote: Hi guys, See below Dave - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, July 20, 2007 1:59 PM Subject: Re: Conversational - spec question Simon Laws wrote: On 7/20/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, It is clear from reading other sections of the specification that it is intended that @ConversationID is used in implementation classes other than those of CONVERSATION scope. Further down in 1.2.51 of the JavaComponentImplementation spec, it says the following: 1. The implementation can be built as a stateless piece of code (essentially, the code expects a new instance of the code to be used for each method invocation). The code must then be responsible for accessing the conversationID of the conversation, which is maintained by the SCA runtime code. The implementation is then responsible for persisting any necessary state data during the processing of a method and for accessing the persisted state data when required, all using the conversationID as a key. This is clear that stateless (ie NOT CONVERSATION scope) implementations can use the conversationID. So I think that @ConversationID is always actioned - the only difference is how often it gets actioned (a CONVERSATION scoped implementation gets it just the once, while every invocation of a stateless will require injection). Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks Mike So if I understand correctly: - a stateless-scoped component is injected with the conversation id when the request is presented to it - a composite-scoped component is injected with the conversation id when the request is presented to it - a conversation-scoped component is injected once with the conversation id when it's created (I see this as an optimization) I was assuming that we were not going to present concurrent requests to a composite-scoped component (we should serialize them), so it shouldn't be a problem? However, I couldn't find a statement in the spec about serialization of concurrent requests targeting composite-scoped components. Can a composite-scoped component be presented with concurrent requests? Composite scoped components can have concurrent requests inflight, the runtime does not need to serialize for concurrency. I recall having this conversation during the spec work, but cant find verbiage in the specs. FWIW, I recall that for composite scoped components, we decided that it was not possible to inject @ConversationID nor callback references, AND therefore the component implementation would have to use the appropriate API which would return the correct info in the context of the request. I am wondering if we are talking about the same thing here. In my post I was talking about the destination endpoint that will be used for the callback. Is there an API to access this information and to direct a callback to the correct endpoint? How would this be done safely with almost simultaneous injection of two different callback endpoints into a composite-scoped component? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Conversational - spec question
[snip] scabooz wrote: Composite scoped components can have concurrent requests inflight, the runtime does not need to serialize for concurrency. I recall having this conversation during the spec work, but cant find verbiage in the specs. FWIW, I recall that for composite scoped components, we decided that it was not possible to inject @ConversationID nor callback references, AND therefore the component implementation would have to use the appropriate API which would return the correct info in the context of the request. This seems to be in line with what I'm proposing at the bottom of http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20535.html Some combinations are not supported, let's get this clarified in the spec first, and when the behavior is clarified we can implement a check in Tuscany to enforce it. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-1474) Unable to create two SCA services that use the Web Service binding
Thanks, Raymond. Increasing the timeout got me past this problem. Simon Raymond Feng (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514487 ] Raymond Feng commented on TUSCANY-1474: --- Hi, Simon. I just ran your test case with the the latest trunk code and it was successful without any errors both in Eclipse and maven. The sleep method may need a longer timout value in some cases. Thanks, Raymond Unable to create two SCA services that use the Web Service binding -- Key: TUSCANY-1474 URL: https://issues.apache.org/jira/browse/TUSCANY-1474 Project: Tuscany Issue Type: Bug Components: Java SCA Tomcat Integration Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Priority: Blocker Fix For: Java-SCA-Next Attachments: simple-callback2-ws.zip As part of debugging the servlet is not available problem (see [1]), I converted simple-callback-ws to use matched pairs of services and references instead of callbacks, and I got exactly the same error. It seesms that no more than one Tomcat Axis2 servlet can be registered, which means that it's not possible to have more than one SCA service that uses the Web Service binding. This is a blocking defect for my work to support callbacks across the Web Service binding. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20548.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1474) Unable to create two SCA services that use the Web Service binding
[ https://issues.apache.org/jira/browse/TUSCANY-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng resolved TUSCANY-1474. --- Resolution: Invalid Simon confirmed that increasing the timeout got him past this problem. Unable to create two SCA services that use the Web Service binding -- Key: TUSCANY-1474 URL: https://issues.apache.org/jira/browse/TUSCANY-1474 Project: Tuscany Issue Type: Bug Components: Java SCA Tomcat Integration Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Priority: Blocker Fix For: Java-SCA-Next Attachments: simple-callback2-ws.zip As part of debugging the servlet is not available problem (see [1]), I converted simple-callback-ws to use matched pairs of services and references instead of callbacks, and I got exactly the same error. It seesms that no more than one Tomcat Axis2 servlet can be registered, which means that it's not possible to have more than one SCA service that uses the Web Service binding. This is a blocking defect for my work to support callbacks across the Web Service binding. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20548.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding support for Contribution Import/Export
Luciano Resende wrote: Trying to go further with the support of import/export, looks like at some cases we need specialized resolvers that understand better the specifics of the artifact type being resolved, I started looking into this piece and will start adding some support for plugable resolvers in the contribution service and then integrate then with the current support for import/export. Thoughts ? On 7/13/07, Luciano Resende [EMAIL PROTECTED] wrote: I have just committed initial support for import/export, the integration tests exercise and demonstrates the usage of multiple contributions using import/export scenarios, there is also a strawman documentation available on the wiki [1]. This is working in progress, and I will look a little more into it to optimize the algorithm being used on the resolution mechanism of the imports. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Contribution+-+Import+and+Export On 7/11/07, Luciano Resende [EMAIL PROTECTED] wrote: I have started looking into contribution import/export as defined in the SCA 1.0 Assembly spec. I've started putting together some test cases around the following scenarios : - Two contributions, where C1 defines and exports CompositeA and C2 imports and reference it trough a implementation.composite - Two contributions, where C1 defines a WSDL contract and export it's namespace, and C2 imports and reference it through a ws-binding. - Two contributions, where C1 defines some interfaces and export it's package, and C2 imports and reference these interfaces I'll start checking in the test-cases, and then working on adding support for contribution service to handle these cases. Please comment on these scenarios, and feel free to add to it, and off course, help is always welcome. The pluggable model resolvers look good to me. On top of this I think we need to support several types of imports/exports: - Namespace based import/export - Java package name based import.java/export.java - other import/export types for other definition types So we're going to need an extensibility mechanism similar to what we already have for bindings and implementation types. In fact it's so similar that I'd suggest to use the same extension point mechanism with StAXArtifactProcessors for the different types of imports/exports. As a first step to enable this, I have created new base Import/Export interfaces suitable all import/export types and NamespaceImport/NamespaceExport interfaces to represent the namespace based imports/exports. When we add JavaImport/JavaExport they'll be able to extend Import/Export as well. I left the existing ContributionImport/ContributionExport interfaces in place but deprecated (they just extend the new NamespaceImport/NamespaceExport) to avoid breaking any code that uses them. I adjusted the contribution implementation module to reflect these changes. These changes are available in revision r558558. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1469) Callbacks over Web Service binding don't work correctly
[ https://issues.apache.org/jira/browse/TUSCANY-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-1469: Attachment: patch3 patch3 contains the remaining changes needed to get the code working correctly with the new implementation. With this patch, the old implementation code path has been removed, which makes the code much easier to read. In addition to applying the changes in this patch, the following files that are part of the old implementation must be removed: before rebuilding: Axis2AsyncBindingInvoker.java Axis2ReferenceCallback.java Axis2ReferenceCallbackTargetInvoker.java Axis2ServiceCallbackTargetInvoker.java Axis2ServiceInOutAsyncMessageReceiver.java I have verified this patch on a checkout from this morning my time. I can't verify it on the current code because svn is not functioning for me at the moment. Callbacks over Web Service binding don't work correctly --- Key: TUSCANY-1469 URL: https://issues.apache.org/jira/browse/TUSCANY-1469 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-0.91 Environment: Windows XP Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: patch1, patch1.zip, patch2, patch3 The current Web Service binding implementation of calllbacks has many limitations and is not spec-compliant. This is because it uses the HTTP reply message to carry the callback instead of sending the callback over a separate HTTP reverse connection in which the service side acts an Axis2 client and the reference side acts as an Axis2 server. The addressing information needed by the service-side client to invoke the reference-side server should be sent with the forward call using WS-Addressing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1475) Integrate Model Resolver extensibility with TuscanyExtensionHelper/Implementation-Script
Integrate Model Resolver extensibility with TuscanyExtensionHelper/Implementation-Script Key: TUSCANY-1475 URL: https://issues.apache.org/jira/browse/TUSCANY-1475 Project: Tuscany Issue Type: Improvement Components: Java SCA Script Implementation Extension Affects Versions: Java-SCA-Next Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-Next I'm finding some issues on integrating ModelResolver extensibility with Implementation-Script -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1475) Integrate Model Resolver extensibility with TuscanyExtensionHelper/Implementation-Script
[ https://issues.apache.org/jira/browse/TUSCANY-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1475: - Attachment: IntegratingImportExport.patch Changes that I'm playing with... Integrate Model Resolver extensibility with TuscanyExtensionHelper/Implementation-Script Key: TUSCANY-1475 URL: https://issues.apache.org/jira/browse/TUSCANY-1475 Project: Tuscany Issue Type: Improvement Components: Java SCA Script Implementation Extension Affects Versions: Java-SCA-Next Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-Next Attachments: IntegratingImportExport.patch I'm finding some issues on integrating ModelResolver extensibility with Implementation-Script -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Integrating Model Resolver Extensibility with TuscanyExtensionHelper/Implementation-script
I'm in the process of integrating the Model Resolver extensibility to the DefaultSCADomain, and came across some issues on how the ExtensionHelper is performing resolution of component types, looks like it traverse all the models in the ModelResolver to find any componentTypes [1]. I was trying to use the resolver to actually resolve the componentType, but looks like there isn't enough information on the PojoImplementation, as the call to SCDLProcessor.addSideFileComponentType always get the name parameter as null, and impl.getUri() is also always null. Can someone more familiar with the ExtensionHelper/implementation-script give me some hints on what tasks need to be performed during the resolve phase ? I'll be on IRC, if a quick chat is easier. I have made a patch available on the following JIRA[2], in case people can give some help. [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/SCDLProcessor.java [2] https://issues.apache.org/jira/browse/TUSCANY-1475 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integrating Model Resolver Extensibility with TuscanyExtensionHelper/Implementation-script
Luciano Resende wrote:
I'm in the process of integrating the Model Resolver extensibility to
the DefaultSCADomain, and came across some issues on how the
ExtensionHelper is performing resolution of component types, looks
like it traverse all the models in the ModelResolver to find any
componentTypes [1]. I was trying to use the resolver to actually
resolve the componentType, but looks like there isn't enough
information on the PojoImplementation, as the call to
SCDLProcessor.addSideFileComponentType always get the name parameter
as null, and impl.getUri() is also always null.
Can someone more familiar with the
ExtensionHelper/implementation-script give me some hints on what tasks
need to be performed during the resolve phase ? I'll be on IRC, if a
quick chat is easier.
I have made a patch available on the following JIRA[2], in case people
can give some help.
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/SCDLProcessor.java
[2] https://issues.apache.org/jira/browse/TUSCANY-1475
The logic in getComponentType looks like it's trying all componentTypes
against all properties of the bean. I think this needs to be cleaned up
a little as it'll lead to pretty unpredictable behavior but in the
meantime, try this:
private ComponentType getComponentType(ModelResolver resolver,
Implementation impl) throws IllegalArgumentException,
IllegalAccessException, InvocationTargetException {
for (Method m : getGetters()) {
Object io;
if (impl instanceof PojoImplementation) {
io = ((PojoImplementation)impl).getUserImpl();
} else {
io = impl;
}
String value = (String) m.invoke(io, new Object[]{});
if (value != null) {
value = value.substring(0, value.lastIndexOf('.'));
ComponentType componentType =
assemblyFactory.createComponentType();
componentType.setUnresolved(true);
componentType.setURI(value + .componentType);
componentType =
resolver.resolveModel(ComponentType.class, componentType);
if (!componentType.isUnresolved()) {
return componentType;
}
}
}
return null;
}
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integrating Model Resolver Extensibility with TuscanyExtensionHelper/Implementation-script
Thanks Sebastien, all working now.
On 7/22/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Luciano Resende wrote:
I'm in the process of integrating the Model Resolver extensibility to
the DefaultSCADomain, and came across some issues on how the
ExtensionHelper is performing resolution of component types, looks
like it traverse all the models in the ModelResolver to find any
componentTypes [1]. I was trying to use the resolver to actually
resolve the componentType, but looks like there isn't enough
information on the PojoImplementation, as the call to
SCDLProcessor.addSideFileComponentType always get the name parameter
as null, and impl.getUri() is also always null.
Can someone more familiar with the
ExtensionHelper/implementation-script give me some hints on what tasks
need to be performed during the resolve phase ? I'll be on IRC, if a
quick chat is easier.
I have made a patch available on the following JIRA[2], in case people
can give some help.
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/SCDLProcessor.java
[2] https://issues.apache.org/jira/browse/TUSCANY-1475
The logic in getComponentType looks like it's trying all componentTypes
against all properties of the bean. I think this needs to be cleaned up
a little as it'll lead to pretty unpredictable behavior but in the
meantime, try this:
private ComponentType getComponentType(ModelResolver resolver,
Implementation impl) throws IllegalArgumentException,
IllegalAccessException, InvocationTargetException {
for (Method m : getGetters()) {
Object io;
if (impl instanceof PojoImplementation) {
io = ((PojoImplementation)impl).getUserImpl();
} else {
io = impl;
}
String value = (String) m.invoke(io, new Object[]{});
if (value != null) {
value = value.substring(0, value.lastIndexOf('.'));
ComponentType componentType =
assemblyFactory.createComponentType();
componentType.setUnresolved(true);
componentType.setURI(value + .componentType);
componentType =
resolver.resolveModel(ComponentType.class, componentType);
if (!componentType.isUnresolved()) {
return componentType;
}
}
}
return null;
}
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1454) binding.ws malfunction with customer data types
[ https://issues.apache.org/jira/browse/TUSCANY-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 耿韶光 updated TUSCANY-1454: - Attachment: Tuscany.0717.rar Hi, I explored Tuscany java sca in an eclipse workspace, expand my attachment you will see this workspace. I deleted some big metadata and class files, so please rebuild all the content first, and run the binding.ws from eclipse's run::HelloWorldServer. To simplify the test, I created a test plan in jakarta-jmeter, you could create a SOAP/XML-RPC Request and write the soap as: soap:Envelope xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; xmlns=http://helloworld; soap:Body getGreetings namexSx/name age200/age /getGreetings /soap:Body /soap:Envelope First you run the jmeter-test, the soap will be responded correctly, but will not for the following. Change the wsdl and java files inside ws-service project, to find out the difference. To trace the class, just set break point in the Tuscany sources in other projects. Tuscany source code of this workspace is the SVN files at Jul.17. binding.ws malfunction with customer data types --- Key: TUSCANY-1454 URL: https://issues.apache.org/jira/browse/TUSCANY-1454 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-Next Environment: winXP, java5, sca java svn Reporter: 耿韶光 Attachments: Tuscany.0717.rar I was working with Tuscany's binding.ws these two days, I established a service provider. I found that if the element type is base types(xsd type such as int, string), it worked find. Since I remember a mail in the list has metiond complexTypes doesn't work some what. So I tried this out, and, it was . The service just worked the first time it was accessed, then I refused to work any more. I traced the code for some depth, I found the error came from a dom instance was always held, and the same dom serves all the following request, then a error checking method produces a Exception. I will look into these code next monday, for the time being, I cry this out, wish some one could devote. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1475) Integrate Model Resolver extensibility with TuscanyExtensionHelper/Implementation-Script
[ https://issues.apache.org/jira/browse/TUSCANY-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1475. -- Resolution: Fixed Integrated under revision #558587 Integrate Model Resolver extensibility with TuscanyExtensionHelper/Implementation-Script Key: TUSCANY-1475 URL: https://issues.apache.org/jira/browse/TUSCANY-1475 Project: Tuscany Issue Type: Improvement Components: Java SCA Script Implementation Extension Affects Versions: Java-SCA-Next Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-Next Attachments: IntegratingImportExport.patch I'm finding some issues on integrating ModelResolver extensibility with Implementation-Script -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1353) Exception attempting to insert rows using DAS w/DataDirect JDBC driver
[ https://issues.apache.org/jira/browse/TUSCANY-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514556 ] Amita Vadhavkar commented on TUSCANY-1353: -- Yes, Ron, config attribute and check for databasemetadata.supportsGetGeneratedKeys() can be provided. Also, just in case the database driver does not support supportsGetGeneratedKeys() method itself, the code can catch the exception and force useGetGeneratedKeys to FALSE. Exception attempting to insert rows using DAS w/DataDirect JDBC driver -- Key: TUSCANY-1353 URL: https://issues.apache.org/jira/browse/TUSCANY-1353 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-M2 Environment: Windows XP, WebLogic 8.1SP6, Sybase 12.5, DataDirect Sybase JDBC driver (embedded within BEA WebLogic) Reporter: Ron Gavlin Priority: Critical Greetings, I am having problems inserting rows with Tuscany DAS M2 using the BEA WebLogic Sybase JDBC driver (DataDirect Connect for JDBC 3.6 June 2007)) which is an embedded version of the popular DataDirect JDBC driver. Although I have not tested it, I suspect this problem appears in non-Sybase versions of the driver as well. The code below generates the listed stacktrace. Note: BEA apparently renames the DataDirect Connect for JDBC classes as part of its embedding process. ... Command insert = das.createCommand(insert into Test (testCol1, testCol2) values (?, ?)); insert.setParameter(1, str1); insert.setParameter(2, str2); insert.execute(); Stacktrace: Caused by: java.sql.SQLException: [BEA][Sybase JDBC Driver]No rows affected. at weblogic.jdbc.base.BaseExceptions.createException(Unknown Source) at weblogic.jdbc.base.BaseException.getException(Unknown Source) at weblogic.jdbc.base.BaseStatement.executeUpdateInternal(Unknown Source) at weblogic.jdbc.base.BasePreparedStatement.executeUpdate(Unknown Source) at weblogic.jdbc.wrapper.PreparedStatement.executeUpdate(PreparedStatement.java:159) at org.apache.tusany.das.rdb.impl.Statement.executeUpdate(Statement.java:173) at org.apache.tusany.das.rdb.impl.Statement.executeUpdate(Statement.java:133) at org.apache.tusany.das.rdb.impl.InsertCommandImpl.execute(InsertCommandImpl.java:44) While interactively debugging org.apache.tuscany.das.rdb.impl.ConnectionImpl.prepareStatement(String queryString, String[] returnKeys), I noticed if I manually change the boolean member variable useGetGeneratedKeys to false, no exception is generated and the insert works as designed. The DataDirect Connect for JDBC drivers are either supported or embedded into numerous commercial application servers, including IBM WebSphere 6.1, jBoss 4.x, and BEA WebSphere. Folks using these platforms are likely to quickly hit this problem if they attempt to use the DAS. - Ron -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1469) Callbacks over Web Service binding don't work correctly
[ https://issues.apache.org/jira/browse/TUSCANY-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng resolved TUSCANY-1469. --- Resolution: Fixed The 3rd patch has been applied under r558614. Thanks, Raymond Callbacks over Web Service binding don't work correctly --- Key: TUSCANY-1469 URL: https://issues.apache.org/jira/browse/TUSCANY-1469 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-0.91 Environment: Windows XP Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: patch1, patch1.zip, patch2, patch3 The current Web Service binding implementation of calllbacks has many limitations and is not spec-compliant. This is because it uses the HTTP reply message to carry the callback instead of sending the callback over a separate HTTP reverse connection in which the service side acts an Axis2 client and the reference side acts as an Axis2 server. The addressing information needed by the service-side client to invoke the reference-side server should be sent with the forward call using WS-Addressing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
