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+Response+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