Re: Spring beans xml sca namespace
Debugging through the code it turns out the the current Tuscany implementation already supports both namespaces. There is a bunch of Tuscany code only for the old namespace but none of that appears to ever get used. I'm not sure how that will turn out as the OASIS conformance support gets done but for now i'll just leave it as is. ...ant On Thu, Feb 24, 2011 at 4:51 PM, Raymond Feng enjoyj...@gmail.com wrote: For compatibility reason, can we have Tuscany handle both namespaces for now? Raymond Feng Sent from my iPhone On Feb 24, 2011, at 6:21 AM, Mike Edwards mike.edwards.inglen...@gmail.com wrote: On 23/02/2011 13:13, ant elder wrote: The current Tuscanyimplementation.spring code is still using the old OSOA namespace for the sca extensions to the Spring context files. As FYI I plan to update that shortly in trunk, which does mean any existing sca spring applications would need updating if they're using the SCA extensions. ...ant +1 - this does need doing. I assume that this is a 2.x statement and that 1.x will remain unchanged? Do you need help with the 2.x changes? Yours, Mike.
Re: [VOTE] Release Tuscany SCA 2.0 Beta2 RC3
Anybody having information on the ASF blog and twitter account? On Thu, Feb 24, 2011 at 12:17 PM, Florian Moga moga@gmail.com wrote: Just got it. Thanks! On Thu, Feb 24, 2011 at 12:15 PM, Simon Laws simonsl...@googlemail.comwrote: On Wed, Feb 23, 2011 at 7:30 PM, Florian Moga moga@gmail.com wrote: Can you please add me to the contributors for the Tuscany blog with my gmail address so I can post the release announcement? Also, is it possible to post an announcement on the ASF blog [1] and ASF Twitter account [2]? [1] http://blogs.apache.org/foundation/ [2] http://twitter.com/#!/TheASF Hi Florian I just clicked the button to send you an invite to be a blog author. Let me know if you don't get it. Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] Closed: (TUSCANY-3839) Generic reference policy interceptors are not being added to the reference chain
[ https://issues.apache.org/jira/browse/TUSCANY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3839. --- Resolution: Fixed Fix Version/s: Java-SCA-2.x Fox committed at revision: 1074462 Generic reference policy interceptors are not being added to the reference chain Key: TUSCANY-3839 URL: https://issues.apache.org/jira/browse/TUSCANY-3839 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta2 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.x The RuntimeEndpointReference.addReferenceBindingInterceptor() method should create a normal interceptor and not a binding interceptor. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Following up on Gang's thread about policy handling in 1.x and getting the right effect when trying to apply security policy with the Web Services binding I'm looking at how policy is applied in 2.x. I've created a test case [1] which has three components with the same implementation: component name=HelloworldComponent1 implementation.java class=sample.HelloworldImpl/ reference name=hwRef target=HelloworldComponent2 requires=tuscany:interaction.bindingws policySets=tuscany:InteractionBindingWS/ property name=componentName value=HelloworldComponent1/ /component component name=HelloworldComponent2 implementation.java class=sample.HelloworldImpl/ service name=Helloworld requires=tuscany:interaction.bindingws policySets=tuscany:InteractionBindingWS binding.ws/ /service reference name=hwRef target=HelloworldComponent3/ property name=componentName value=HelloworldComponent2/ /component component name=HelloworldComponent3 implementation.java class=sample.HelloworldImpl/ property name=componentName value=HelloworldComponent3/ /component I've added three components so I can look at the context propagation issue across the central component but for now I'm looking at how policy interceptors are applied in relation to the WS binding used between HelloworldComponent1 and HelloworldComponent2. To facilitate this you can see that I've added an interaction policy that has parts with are specific to binding ws. It's intended to demonstrate adding A generic policy interceptor in the Tuscany operation chain A binding specific policy interceptor in the Tuscany binding chain An Axis handler added by the policy This test policy isn't configurable and the providers are hard coded to add the appropriate handlers [2] [3]. The result is the following sequence for the forward an response message passing between the two components. TestPolicyInterceptor.processRequest() HelloworldComponent1#reference-binding(hwRef/Helloworld) @ reference.policy TestPolicyInterceptor.processRequest() HelloworldComponent1#reference-binding(hwRef/Helloworld) @ reference.binding.policy TestAxisHandler.invoke() Reference OutFlow Handler TestAxisHandler.invoke() Service InFlow Handler TestPolicyInterceptor.processRequest() HelloworldComponent2#service-binding(Helloworld/Helloworld) @ service.binding.policy TestPolicyInterceptor.processRequest() HelloworldComponent2#service-binding(Helloworld/Helloworld) @ service.policy TestPolicyInterceptor.processResponse() HelloworldComponent2#service-binding(Helloworld/Helloworld) @ service.policy TestPolicyInterceptor.processResponse() HelloworldComponent2#service-binding(Helloworld/Helloworld) @ service.binding.policy TestAxisHandler.invoke() Service OutFlow Handler TestAxisHandler.invoke() Reference InFlow Handler TestPolicyInterceptor.processResponse() HelloworldComponent1#reference-binding(hwRef/Helloworld) @ reference.binding.policy TestPolicyInterceptor.processResponse() HelloworldComponent1#reference-binding(hwRef/Helloworld) @ reference.policy Which looks OK on the face of it but looking in detail I find that the service side binding interceptor is happening outside the context of the Axis binding. So I'm going to look at fixing that first. Then I'll look at each of the issues that Gang raised and see if/how this infrastructure provides a solution. [1] http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/testing/itest/interceptors/ [2] http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/testing/itest/interceptors/src/main/java/sample/InteractionBindingWSReferencePolicyProvider.java [3] http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/testing/itest/interceptors/src/main/java/sample/InteractionBindingWSServicePolicyProvider.java Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: 2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
I Think the following are the issues that Gang has raised across the various mail threads. I'll add 2.x comments shortly. TUSCANY-3822 - Service side afterInvoker should be called with the outbound Axis MC Gang has correct the call to afterInvoke. Demonstrated in two attachments to JIRA. There is some discussion of what the sequence of calls should be for different MEPs, for example, in-only: beforeInvoke(inMC) / afterInvoke(inMC) in-out: beforeInvoke(inMC) / afterInvoke(outMC) out-only: beforeInvoke(outMC) Gang's summary comment 1. PolicyHandler.afterInvoke() needs to be called with the outbound MessageContext instead of the inbound MC. This is critical for WS-security. I have provided my fixes in the JIRA. With some generalization we discussed, I think this should be fixable in 1.6.x TUSCANY-3838 - Reference side afterInvoke is skipped when AxisFault occurs Gang has corrected the call to afterInvoke in a patch attached to the JIRA Sub categories of this issue 1. On the service side, any business exceptions from the implementation cause afterInvoke() to be skipped. Tuscany creates an AxisFault wrapping the business exception, and throws this back to Axis2 for it to generate the on-the-wire fault. 2. On the service side, any system exceptions from the implementation (e.g., ServiceRuntimeException) or from beforeInvoke() cause afterInvoke() to be skipped. Tuscany creates an AxisFault by calling AxisFault.makeFault() and throws this back to Axis2 for it to generate the on-the-wire fault. 3. On the reference side, any AxisFault (either created by Axis2 or created by Tuscany on the service side because of cases 1 or 2) causes afterInvoke() to be skipped. Gang's summary comment 4. PolicyHandler.afterInvoke is not called when Fault is generated. So far, I have no workaround on this and would like a fix. If I remember the code correctly, a quick fix is possible if Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic() can catch the exception, create the Fault body and call PolicyHandler.afterInvoke() on the service side. I'm not sure how the client (requester) side works, but the PolicyHandler.afterInvoke() is also skipped on the return with the Fault. TUSCANY- - Default dispatching mechanism in Axis depends on looking at the wrapper element name Gang added @WebMethod to the interfaces to drive the generation of SOAPAction which Axis will use to select the service operation The alternative is to use MessageContext.setSoapAction() in the interceptor that does the encryption Gang's summary comment 2. SOAP message encryption is not supported because the PolicyHandler.beforeInvoke() is called after Axis2 dispatching phase, which needs to analize SOAP body in order to determine the endpoint method. This can be worked around by defining SOAPaction in WSDL or Java interface using @WebMethod. However, a future fix is still nice to have. TUSCANY- - We need to be able to pass context through a component implementation so, for example, the security context established when a service is called is available to references of that service. (1) service binding.ws - (2) handlers - (3) component implementation - (4) handlers - (6) reference binding.ws Lots of discussion see, for example, http://www.mail-archive.com/dev@tuscany.apache.org/msg15581.html We need to distil this into a proposal for 2.x Gang's summary comment 3. A state-sharing mechanism is needed to allow sharing states among service side interceptors/handlers, component and reference side interceptors/handlers. I'm currently using the ThreadLocal as a workaround, which I wish to have your blessing - for now, it's only used from the service handler to component and then to reference handler and I hope you can confirm that the same thread is used for processing. However, we all agreed that this is not desirable to use ThreadLocal in the service framework and a state-sharing mechanism is needed. TUSCANY- - Where should interceptors be looking for message information. Axis MC, Tuscany Message or both and should the interceptor be fixing up the relationship between the two when encrypting/decrypting In 2.x he binding chain is binding specific so has the oppotunity to do whatever it needs to do with both structures We would expect the writier of one of these interceptors to understand both Axis and Tuscany internals. Gang, you offered to send in you 2.0 policy prototype code a one stage in the various conversations. Could you do this bay attaching it to a new JIRA? Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: 2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Let me try that again with formatting and with 2.x comments As previously discussed the 2,x binding specific interceptor model is different from the 1.x model. Policy processing can intercept the message flow in two places Generically on the operation specific wire In a binding specific way on the binding wire The binding specific processing is free to (re-)configure the binding as appropriate. For example it can add Axis handlers. Back to the issues. This time with 2.x comments attached. TUSCANY-3822 - Service side afterInvoker should be called with the outbound Axis MC Gang has correct the call to afterInvoke. Demonstrated in two attachments to JIRA. There is some discussion of what the sequence of calls should be for different MEPs, for example, in-only: beforeInvoke(inMC) / afterInvoke(inMC) in-out: beforeInvoke(inMC) / afterInvoke(outMC) out-only: beforeInvoke(outMC) Gang's summary comment == 1. PolicyHandler.afterInvoke() needs to be called with the outbound MessageContext instead of the inbound MC. This is critical for WS-security. I have provided my fixes in the JIRA. With some generalization we discussed, I think this should be fixable in 1.6.x 2.x comments === Binding interceptors have access to the binding context which in the reference side is OperationClient which holds out and in MessageContext. On the service side it's the in MessageContext from which I believe you can get the out MessageContext. We need to look whether this asymmetry is necessary TUSCANY-3838 - Reference side afterInvoke is skipped when AxisFault occurs Gang has corrected the call to afterInvoke in a patch attached to the JIRA Sub categories of this issue 1. On the service side, any business exceptions from the implementation cause afterInvoke() to be skipped. Tuscany creates an AxisFault wrapping the business exception, and throws this back to Axis2 for it to generate the on-the-wire fault. 2. On the service side, any system exceptions from the implementation (e.g., ServiceRuntimeException) or from beforeInvoke() cause afterInvoke() to be skipped. Tuscany creates an AxisFault by calling AxisFault.makeFault() and throws this back to Axis2 for it to generate the on-the-wire fault. 3. On the reference side, any AxisFault (either created by Axis2 or created by Tuscany on the service side because of cases 1 or 2) causes afterInvoke() to be skipped. Gang's summary comment == 4. PolicyHandler.afterInvoke is not called when Fault is generated. So far, I have no workaround on this and would like a fix. If I remember the code correctly, a quick fix is possible if Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic() can catch the exception, create the Fault body and call PolicyHandler.afterInvoke() on the service side. I'm not sure how the client (requester) side works, but the PolicyHandler.afterInvoke() is also skipped on the return with the Fault. 2.x comments === We're going to have to think through this one. We instigated a pattern for the async work that we can potentially exploit. I'll add faults to the test. TUSCANY- - Default dispatching mechanism in Axis depends on looking at the wrapper element name Gang added @WebMethod to the interfaces to drive the generation of SOAPAction which Axis will use to select the service operation The alternative is to use MessageContext.setSoapAction() in the interceptor that does the encryption Gang's summary comment == 2. SOAP message encryption is not supported because the PolicyHandler.beforeInvoke() is called after Axis2 dispatching phase, which needs to analize SOAP body in order to determine the endpoint method. This can be worked around by defining SOAPaction in WSDL or Java interface using @WebMethod. However, a future fix is still nice to have. 2.x comments === I need to run some experiments on this but it looks like the TuscanyDispatcher in 2.x is coded to dispatch off the URL. I don't know under what circumstances this is used and whether we support other dispatching mechanisms TUSCANY- - We need to be able to pass context through a component implementation so, for example, the security context established when a service is called is available to references of that service. (1) service binding.ws - (2) handlers - (3) component implementation - (4) handlers - (6) reference binding.ws Lots of discussion see, for example, http://www.mail-archive.com/dev@tuscany.apache.org/msg15581.html Gang's summary comment == 3. A state-sharing mechanism is needed to allow sharing states among service side
RE: 2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE Hi, Simon, Very good summary. My comments follow. Gang -Original Message- From: Simon Laws [mailto:simonsl...@googlemail.com] Sent: Friday, February 25, 2011 12:18 PM To: dev@tuscany.apache.org Subject: Re: 2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED) Let me try that again with formatting and with 2.x comments As previously discussed the 2,x binding specific interceptor model is different from the 1.x model. Policy processing can intercept the message flow in two places Generically on the operation specific wire In a binding specific way on the binding wire The binding specific processing is free to (re-)configure the binding as appropriate. For example it can add Axis handlers. Back to the issues. This time with 2.x comments attached. TUSCANY-3822 - Service side afterInvoker should be called with the outbound Axis MC Gang has correct the call to afterInvoke. Demonstrated in two attachments to JIRA. There is some discussion of what the sequence of calls should be for different MEPs, for example, in-only: beforeInvoke(inMC) / afterInvoke(inMC) in-out: beforeInvoke(inMC) / afterInvoke(outMC) out-only: beforeInvoke(outMC) Gang's summary comment == 1. PolicyHandler.afterInvoke() needs to be called with the outbound MessageContext instead of the inbound MC. This is critical for WS-security. I have provided my fixes in the JIRA. With some generalization we discussed, I think this should be fixable in 1.6.x 2.x comments === Binding interceptors have access to the binding context which in the reference side is OperationClient which holds out and in MessageContext. On the service side it's the in MessageContext from which I believe you can get the out MessageContext. We need to look whether this asymmetry is necessary In addition to what is accessible, there's also a timing issue, which is also critical. Take the afterInvoke in 1.6.x as an example. Even though you may be able to get out MessageContext from in MessageContext, it's also critical when afterInvoke is called. Before my changes, afterInvoke is called at a time where out MessageContext has not been set up correctly. Conceptually, out MessageContext is more natural on the return direction. TUSCANY-3838 - Reference side afterInvoke is skipped when AxisFault occurs Gang has corrected the call to afterInvoke in a patch attached to the JIRA Sub categories of this issue 1. On the service side, any business exceptions from the implementation cause afterInvoke() to be skipped. Tuscany creates an AxisFault wrapping the business exception, and throws this back to Axis2 for it to generate the on-the-wire fault. 2. On the service side, any system exceptions from the implementation (e.g., ServiceRuntimeException) or from beforeInvoke() cause afterInvoke() to be skipped. Tuscany creates an AxisFault by calling AxisFault.makeFault() and throws this back to Axis2 for it to generate the on-the-wire fault. 3. On the reference side, any AxisFault (either created by Axis2 or created by Tuscany on the service side because of cases 1 or 2) causes afterInvoke() to be skipped. Gang's summary comment == 4. PolicyHandler.afterInvoke is not called when Fault is generated. So far, I have no workaround on this and would like a fix. If I remember the code correctly, a quick fix is possible if Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic() can catch the exception, create the Fault body and call PolicyHandler.afterInvoke() on the service side. I'm not sure how the client (requester) side works, but the PolicyHandler.afterInvoke() is also skipped on the return with the Fault. 2.x comments === We're going to have to think through this one. We instigated a pattern for the async work that we can potentially exploit. I'll add faults to the test. The JIRA TUSCANY-3838 is only for the sub category 3 per Simon N.'s categorization. The other two don't have JIRA's yet. In the subsequent discussions, Simon and I had concluded that a fix for sub categories 1 2 are non-trivial because the actual AxisFault processing that creates the SOAPFault body happens much later on for afterInvoke to be invoked. But in 2.x, if a separate interceptor can be inserted on the return path, then this can be solved easily and naturally. TUSCANY- - Default dispatching mechanism in Axis depends on looking at the wrapper element name Gang added @WebMethod to the interfaces to drive the generation of SOAPAction which Axis will use to select the service operation The
