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/[email protected]/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
