----- Original Message -----
From: "Simon Nash" <n...@apache.org>
To: <dev@tuscany.apache.org>
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
