Classification: UNCLASSIFIED Caveats: NONE
> -----Original Message----- > From: Simon Nash [mailto:n...@apache.org] > Sent: Sunday, February 20, 2011 4:06 PM > To: dev@tuscany.apache.org > 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. > > 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 Hi, Simon, I have not been able to find any workaround for case 1 and 2. I can see in the debugger that the generation of response message from the AxisFault happens much later and I agree with you that it's not a simple fix. It looks to me that I have to live with it. It's not the end of world since we achieved the main goal by blocking the request in beforeInvoke. It's just the response that is not gracefully handled by security process. For case 3, will afterInvoke will be called with the response MessageContext that contains the response SOAP message? If so, I would like your proposed workaround/fix for case 3 to be included if possible. It'll give us a compatible Fault handling with other services (non-Tuscany). It'll also enable auditing when Fault occurs. Thanks, Gang Classification: UNCLASSIFIED Caveats: NONE
