Jim, My gut feeling is that this validation and exception belong in the MAPAggregator, not the PolicyInInterceptor. If Addressing is required, the addressing layer should throw the appropriate addressing fault.
Dan On Jul 5, 2010, at 4:02 AM, jim ma <[email protected]> wrote: > Hi all , > > When I ran a service with ws addressing policy enabled and an handler > which always throw exception configured in > server side . When I sent a soap request WITHOUT wsa header , > I saw the SOAPHandlerInterceptor in server side eat the WS addressing > violation exception and just throw the exception > in handler chain thrown . > > Below is the intercetor chain sequence in server side and my analysis > comments : > > -----------org.apache.cxf.ws.policy.policyinintercep...@184b5c4 > > #Add the wsa policy interceptorProvider and > PolicyVerificationIntercetor > > -----------org.apache.cxf.interceptor.attachmentinintercep...@8f299 > -----------org.apache.cxf.transport.https.certconstraintsintercep...@88e798 > -----------org.apache.cxf.interceptor.staxinintercep...@4757b > ----------- org.apache.cxf.binding.soap.interceptor.readheadersintercep...@fe0e2e > ----------- org.apache.cxf.binding.soap.interceptor.soapactioninintercep...@568915 > ----------- org.apache.cxf.binding.soap.interceptor.startbodyintercep...@141dc8b > ----------- org.apache.cxf.binding.soap.interceptor.mustunderstandintercep...@f638ae > -----------org.apache.cxf.ws.addressing.soap.mapco...@178fce9 > > #Here compose the WSA maps and already > know there is no wsa header in inbound soap message > > -----------org.apache.cxf.jaxws.handler.soap.soaphandlerintercep...@187ab2d > > # Here will call the Handler and throw > exception , the execute path will be directed to fault chain, > hence the WS addressing policy error > will not be reported. > > ----------- org.apache.cxf.jaxws.handler.logical.logicalhandlerinintercep...@ca2f5c > ----------- org.apache.cxf.binding.soap.interceptor.checkfaultintercep...@1eb416b > ----------- org.apache.cxf.jaxb.attachment.jaxbattachmentschemavalidationh...@1405eb > -----------org.apache.cxf.interceptor.urimappingintercep...@90baa1 > -----------org.apache.cxf.interceptor.docliteralinintercep...@1ccd087 > ----------- org.apache.cxf.binding.soap.interceptor.soapheaderintercep...@1611006 > -----------org.apache.cxf.ws.addressing.mapaggrega...@1b97041 > -----------org.apache.cxf.interceptor.onewayprocessorintercep...@162fdb2 > ----------- org.apache.cxf.jaxws.interceptors.wrapperclassinintercep...@1fded53 > -----------org.apache.cxf.jaxws.interceptors.swainintercep...@133c109 > -----------org.apache.cxf.jaxws.interceptors.holderinintercep...@c63783 > -----------org.apache.cxf.ws.policy.policyverificationinintercep...@166979a > > #This will not be executed because > SOAPHandlerInterceptor throws exception > > -----------org.apache.cxf.interceptor.serviceinvokerintercep...@172ff2b > > The above interceptor list is the normal execution path without > exception thrown in SOAPHandlerInterceptor. As you can see , > CXF actually can detect the ws addressing policy violation in MAPCodec > and throws the policy error immediately and not pass in > the SOAPHandlerInterceptor. > So far our policy check uses AssertionInfoMap to log the policy error > and checks the policy error in "one point" > PolicyVerification*Interceptor, > The actual policy errors will not be displayed or reported when the > other intercetors throws exceptoin before the check point > So how can we enable our current policy framework to check error in > the interceptor and report it immediately when there is policy error ? > > Cheers, > Jim -- Daniel Kulp [email protected] http://dankulp.com/blog
