Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
- Original Message - From: "Simon Nash" To: Sent: Sunday, February 20, 2011 4:06 PM Subject: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED) Simon Nash wrote: Gang Yang wrote: --- Cut --- 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. I'll take a look at this code and post some comments on how I think the problem could be addressed. Hi Gang, I've looked at this code and it doesn't seem like a simple fix. 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. I'm assuming that both cases 1 and 2 are a problem for what you need to do. Your suggestion of moving responsibility for creating the fault body from Axis2 to Tuscany seems like a big change with plenty of opportunity for things to go wrong because Axis2 would then take different code paths when Tuscany returns back to it. I don't know Axis2 well enough to know whether it is considered correct for the business method to create a fault body as the operation response and return normally instead of throwing an AxisFault. This change could affect other scenarios such as handling business exceptions, so it would need very careful thought and thorough testing. Returning a SOAPFault as normal response if fine. However, I can't effective do so because of code structure. The PolicyHandler API provides two separate methods, beforeInvoke and afterInvoke, for inbound and outbound. When we detect the security problem and want to stop the request from reaching the endpoint in beforeInvoke, we throw runtimeException. But it's this very RuntimeException that prevents afterInvoke on the outbound to be called. So I don't have a chance to create a SOAPFault as a normal response. For case 3, Tuscany could catch the AxisFault, call afterInvoke() and then rethrow the AxisFault. I wouldn't be concerned about making this change because it only affects a small amount of Tuscany code and doesn't have any side effects on Axis2. I think this would help for auditing system and for the case where the remote service side is a non-Tuscany framework. If the remote service side is also a Tuscany framework, then security processing will fail because the service side could not invoke afterInvoke() and therefore did not process security headers. Simon
Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
- Original Message - From: "Simon Nash" To: Sent: Sunday, February 20, 2011 2:51 PM Subject: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED) Simon Nash wrote: Gang Yang wrote: --- Cut --- Tuscany doesn't do any thread switching at the service end of this path. At the reference end, a thread switch will happen if a one-way method is invoked and the reference binding provider's supportsOneWayInvocation() method returns false. Axis2ReferenceBindingProvider returns true from supportsOneWayInvocation(), so you won't get any thread switching when using this reference binding. I'm hoping that this workaround (with its limitation on what reference bindings can be used) will be sufficient to avoid the need to do a fix in 1.x. Actually there is the possibility of a thread switch on the service side as well. It happens between the service binding policy handler and the service binding policy interceptor, so service binding policy interceptors are guaranteed to run on the same thread as the implementation but service binding policy handlers aren't. The thread switch happens only if a one-way method is being invoked and the service binding provider's supportsOneWayInvocation() method returns false. This thread switch won't happen for the Axis2 binding, because the supportsOneWayInvocation() method of Axis2ServiceBindingProvider returns true. Simon Hi, Simon, Thanks for all the responses on a Sunday:-) and this detailed info. I think we are blessed then since we are focussed on WS binding and Axis2 is the only WS binding provider in 1.6.x. Thanks again. Gang
Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Simon Nash wrote: Gang Yang wrote: --- Cut --- 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. I'll take a look at this code and post some comments on how I think the problem could be addressed. Hi Gang, I've looked at this code and it doesn't seem like a simple fix. 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. I'm assuming that both cases 1 and 2 are a problem for what you need to do. Your suggestion of moving responsibility for creating the fault body from Axis2 to Tuscany seems like a big change with plenty of opportunity for things to go wrong because Axis2 would then take different code paths when Tuscany returns back to it. I don't know Axis2 well enough to know whether it is considered correct for the business method to create a fault body as the operation response and return normally instead of throwing an AxisFault. This change could affect other scenarios such as handling business exceptions, so it would need very careful thought and thorough testing. For case 3, Tuscany could catch the AxisFault, call afterInvoke() and then rethrow the AxisFault. I wouldn't be concerned about making this change because it only affects a small amount of Tuscany code and doesn't have any side effects on Axis2. Simon
Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Simon Nash wrote: Gang Yang wrote: --- Cut --- Tuscany doesn't do any thread switching at the service end of this path. At the reference end, a thread switch will happen if a one-way method is invoked and the reference binding provider's supportsOneWayInvocation() method returns false. Axis2ReferenceBindingProvider returns true from supportsOneWayInvocation(), so you won't get any thread switching when using this reference binding. I'm hoping that this workaround (with its limitation on what reference bindings can be used) will be sufficient to avoid the need to do a fix in 1.x. Actually there is the possibility of a thread switch on the service side as well. It happens between the service binding policy handler and the service binding policy interceptor, so service binding policy interceptors are guaranteed to run on the same thread as the implementation but service binding policy handlers aren't. The thread switch happens only if a one-way method is being invoked and the service binding provider's supportsOneWayInvocation() method returns false. This thread switch won't happen for the Axis2 binding, because the supportsOneWayInvocation() method of Axis2ServiceBindingProvider returns true. Simon
Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Gang Yang wrote: --- Cut --- Hi Gang, In general new features are added to 2.x, and 1.x gets bug fixes that are considered important from a user perspective. The issues that you have been raising seem to be a mixture of the above, so I am not quite sure what is the best approach, especially as more issues are continuing to come to light as your work proceeds. Whatever is done for 1.x should be consistent with the longer term direction for 2.x, though it wouldn't be unreasonable for the 1.x solution to be a pragmatic "meets minimum" approach. If these fixes/features are essential for what you need to do, and you're unable to move to 2.x, then I think it makes sense to do a "meets minimum" update to 1.x that would bridge the gap until you are able to move to 2.x. Would it be possible for you to move to 2.x? If not, what are the issues that prevent you from doing this? Simon Hi, Simon N., Thanks for the reply. I understand that 2.x is the future and I agree with your longer term consideration. However, the application side of our projects has been using 1.6.x for some time and from my limited experience with 2.0, it's not backword compatible with 1.6.x due to the namespace and API changes. From the WS-security consideration, even though I did have a 2.0 prototype, which got stuck at the policy extension using interceptor, our effort has mainly been focussed on 1.6.x and got pretty good progress. Adding all these plus an end-of-March delivery, it's impractical for us to move to 2.0 in the immediate future. OK, I understand. Thanks for the explanation. So far, I have raised four issues with 1.6.x (may also apply to 2.0 with the interceptor approach): 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. This seems like the kind of fix we should be doing in 1.x, so I'm fine with adding that. 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. The fix wouldn't be simple because it would change the way Tuscany plugs into Axis2. I don't think we should make this change in 1.x. 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 doesn't do any thread switching at the service end of this path. At the reference end, a thread switch will happen if a one-way method is invoked and the reference binding provider's supportsOneWayInvocation() method returns false. Axis2ReferenceBindingProvider returns true from supportsOneWayInvocation(), so you won't get any thread switching when using this reference binding. I'm hoping that this workaround (with its limitation on what reference bindings can be used) will be sufficient to avoid the need to do a fix in 1.x. 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. I'll take a look at this code and post some comments on how I think the problem could be addressed. Simon Thanks, Gang
Re: [VOTE] Release Tuscany SCA 2.0 Beta2 RC3
Thanks Ant, I've just added my key to the file. It doesn't appear on the website yet. Can we perform a sync or is it done automatically? Considering the amount of work to be done in trunk/ I'm also calling +1 for doing this release. The vote passes with +1 from: Ant Elder Simon Laws Luciano Resende Florian Moga and no -1 votes. Thank you everyone for voting. I'll continue with the next steps I found here https://cwiki.apache.org/confluence/display/TUSCANYxDOCx2x/Making+Releases On Sun, Feb 20, 2011 at 10:41 AM, ant elder wrote: > On Fri, Feb 18, 2011 at 11:22 AM, Florian Moga wrote: > > On Fri, Feb 18, 2011 at 12:17 PM, Simon Laws > > wrote: > >> > >> The only thing I noticed was that RELEASE_NOTES have the wrong date at > >> the top. This is not a blocker IMO. > > > > I could modify it right there if that's allowed. > > > > No we can't modify that now. The contents of the SVN tag should match > whats in the distributions so if its modified in SVN then we'd need to > respin the distributions and have a new vote. > > >> > >> I didn't spend much time on the samples for obvious reasons but the > >> simple ones run. I get a clean build of the source with a clean repo > >> on Linux. > >> > >> MD5 is OK but my remaining question is about getting the KEYS file > >> (http://www.apache.org/dist/tuscany/KEYS) updated with your public > >> key. Ant made comments about keys so maybe this is already in train. > > > > How can I edit the file? My public key is also available here [1]. > > [1] https://svn.apache.org/repos/asf/tuscany/KEYS > > > > Log on to people.apache.org and then you can find that KEYS file at > /x1/www/www.apache.org/content/dist/tuscany > > ...ant >
Re: [VOTE] Release Tuscany SCA 2.0 Beta2 RC3
On Fri, Feb 18, 2011 at 11:22 AM, Florian Moga wrote: > On Fri, Feb 18, 2011 at 12:17 PM, Simon Laws > wrote: >> >> The only thing I noticed was that RELEASE_NOTES have the wrong date at >> the top. This is not a blocker IMO. > > I could modify it right there if that's allowed. > No we can't modify that now. The contents of the SVN tag should match whats in the distributions so if its modified in SVN then we'd need to respin the distributions and have a new vote. >> >> I didn't spend much time on the samples for obvious reasons but the >> simple ones run. I get a clean build of the source with a clean repo >> on Linux. >> >> MD5 is OK but my remaining question is about getting the KEYS file >> (http://www.apache.org/dist/tuscany/KEYS) updated with your public >> key. Ant made comments about keys so maybe this is already in train. > > How can I edit the file? My public key is also available here [1]. > [1] https://svn.apache.org/repos/asf/tuscany/KEYS > Log on to people.apache.org and then you can find that KEYS file at /x1/www/www.apache.org/content/dist/tuscany ...ant
Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)
On Tue, Feb 15, 2011 at 7:08 PM, ant elder wrote: > On Thu, Feb 10, 2011 at 9:10 AM, ant elder wrote: > >> >> I have now done these. There's a beta2 branch for the release, and all >> the trunk samples are now in contrib/samples and the helloworld sample >> is in unreleased/samples where we can continuing with making it like >> we want. >> > > So how do we progress this? What do we need to change in the > helloworld sample at > https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution/ > to make in complete and move it back to trunk/samples? > > ...ant > Ok no comments so if we're all happy with that then in a few days i'll move it back to trunk/samples and use it as a model for the next ones. ...ant
