Classification: UNCLASSIFIED Caveats: NONE Hi, Simon L.,
Forgot to ask. From what you described, it sounds promising in Tuscany 2.0 using interceptors approach. Based on your quick assessment, how complete is Tuscany 2.0 policy interceptor framework? Would it now support the four capabilities I raised and summarized earlier in this thread? If not, would 1 and 4 at least be supported and 2 and 3 be still working using the workaround? Below is the list I copied from earlier post. Of course in the interceptor approach, there wouldn't be before/afterInvoke(), but just invoke, which would invoke the next in the invocation chain and adding logic before and after the next.invoke(). 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. 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. 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. 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. Thanks, Gang > -----Original Message----- > From: Simon Laws [mailto:simonsl...@googlemail.com] > Sent: Tuesday, February 22, 2011 6:18 AM > To: dev@tuscany.apache.org > Subject: Re: PolicyHandler exception handling issue - > PolicyHandler.afterInvoke() is not called when SOAPFault is generated > (UNCLASSIFIED) > > On Tue, Feb 22, 2011 at 9:03 AM, Simon Nash <n...@apache.org> wrote: > > Gang Yang wrote: > >> > >> --- Cut --- > >>> > >>> How about plugging your code into an Axis2 handler instead of a > Tuscany > >>> handler? Is there is a way to get control after Axis2 has built > the > >>> SOAPFault and before the fault is sent on the wire? > >>> > >>> Simon > >>> > >> > >> Our security software has been integrated with Axis2 and other WS > >> frameworks such as JAX-WS and JAX-RPC. The problem here is that we > are > >> supposed to integrate with Tuscany. Axis2 is just a ws binding > provider and > >> it's hidden behind Tuscany:-). In an earlier quick effort, I have > modified > >> tuscany-sca-all-1.6.jar to add Axis2 handlers in a hard-coded way. > But > >> that's not a good solution and it's not flexiable. > >> > >> > > Why do the Axis2 handlers need to be part of the Tuscany jar? Is > this > > a classloader issue? Perhaps there is a way to customize Tuscany's > use > > of classloaders to allow Axis2 handlers to be loaded from outside the > > Tuscany jar. For example, it's possible to set up Tuscany 1.x to run > with > > a different version of Axis2 from that included with the tuscany-sca- > all > > jar, as described in [1] (please read the whole thread). > > > > Simon > > > > [1] http://www.mail-archive.com/user@tuscany.apache.org/msg02597.html > > > > > > Trying to catch up.... > > I think there is a question here of how generic the security code is. > > If it's common code that is intended to encrypt messages regardless of > what binding is used then it needs to be independent of the binding. > It it does depend on the type of binding then things are different. > For WS Security support in 1.x we chose to use the Rampart module of > Axis so our security policies in that area just provide configuration > to the Rampart module. Hence we allow the guts of Axis to do whatever > it needs to do and just provide the appropriate configuration. > > This case of providing a bespoke policy that has to run in the context > of a binding is, as we are finding here, tricky because in 1.x we > started out with an infrastructure model that treated the binding as a > black box. The policy handlers beforeInvoke/afterInvoke were a first > attempt to resolve it but we added then in a very binding specific > way. I.e. where they appear and get called is binding dependent. > > We backed away from this approach for the JMS and HTTP bindings in 1.x > and created the binding chain [1]. We went this route to support > features, such as wireFormat and operationSelection, that the OASIS > specifications introduced. What it does is introduce the familiar > handler infrastructure into the guts of the binding implementation so > opening up the black box and making it more pluggable. So, for > example, on the reference side you might find that a binding does the > following > > Set up the binding context -> some arbitrary handlers (policy, > wireFormat etc) -> transport processing > > And on the service side the reverse is true. > > transport processing -> some arbitrary handlers (policy, wireFormat > etc) -> Operation selection > > In 2.x the JMS and HTTP binding came over from 1.x pretty much as is > and we started converting the ws-axis binding to this pattern. The new > PolicyProvider interface has extra methods [2] which still support > policy interceptors being created for the normal operation chain but > adds the ability to create interceptors for the binding chain and also > allows the provider the opportunity to configure a binding directly if > required. > > Another thing we started looking at in 2.x was alternative > implementations of binding.ws. In particular we started looking at > what it would take to build the binding on top of JAXWS. We have a > simple JDK/RI based version running but didn't get the Axis/JAXWS > version running. We redirected our effort to getting the existing > binding-ws-axis2 binding to being compliant with the OASIS specs. If > someone were to finish off the JAXWS support then in theory you could > add JAXWS interceptors directly the ws binding > > None of this information is directly helping solve Yang's immediate > problem but I want to make sure issues raised on this thread are > resolved in 2.x. I suspect that some of these issues are still > relevant. > > Re. the question of calling afterInvoke() in fault cases. Would there > be problem with letting the infrastructure continue to do the fault > processing but give afterInvoke() a chance to process any faults > created, for example, in Axis2ServiceInOutSyncMessageReceiver .. > > > } catch (InvocationTargetException e) { > Throwable t = e.getCause(); > if (t instanceof FaultException && > ((FaultException)t).getFaultInfo() instanceof OMElement) { > OMElement faultDetail = > (OMElement)((FaultException)t).getFaultInfo(); > inMC.setProperty(Constants.FAULT_NAME, > faultDetail.getQName().getLocalPart()); > AxisFault f = new AxisFault(null, e.getMessage(), > "faultNode", "faultRole", faultDetail); > *** throw f; > } > if (t instanceof Exception) { > *** throw AxisFault.makeFault((Exception)t); > } > logger.log(Level.SEVERE, e.getMessage(), t); > *** throw new ServiceRuntimeException(e); > } catch (Throwable e) { > logger.log(Level.SEVERE, e.getMessage(), e); > *** throw AxisFault.makeFault(e); > } > > give afterInvoke the chance to process here ***. A similar thing could > be done in the invoke() operation of Axis2BindingInvoker. What > processing are you expecting to do on the fault? If you're intending > to encrypt the fault response then this isn't going to work on the > service side as the operation is expecting to throw and exception in > the fault case. > > > [1] > https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Respons > e+Binding > [2] http://svn.apache.org/repos/asf/tuscany/sca-java- > 2.x/trunk/modules/core- > spi/src/main/java/org/apache/tuscany/sca/provider/PolicyProvider.java > > Regards > > Simon > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com Classification: UNCLASSIFIED Caveats: NONE
