Sorry, was reading it on my iPhone and the traces didn't display very well.
I would challenge the test. There isn't anything in the spec that says the addressing stuff needs to be processed before calling the handlers. (example: addressing COULD be implemented as handlers) Thus, the handler in the test should not be throwing the exception or the test should be updated to allow it. Dan On Tuesday 06 July 2010 10:05:16 pm jim ma wrote: > On Wed, Jul 7, 2010 at 8:48 AM, Daniel Kulp <dk...@apache.org> wrote: > > Jim, > > > > My gut feeling is that this validation and exception belong in the > > MAPAggregator, not the PolicyInInterceptor. > > The validation part is in PolicyVerificationInterceptor not > PolicyInInterceptor. > The MAPAgggregator tracks the adderssing policy error in AssertionInfoMap > and PolicyVerificationInterceptor will finally compute and check the > policy configuration to decide if these errors > are needed to be cast to PolicyException and throw. > > > If Addressing is required, the > > addressing layer should throw the appropriate addressing fault. > > As you can see from the interceptor chain list , the current chain > will NOT reach MAPAggregator which can validate the incoming > addressing properties when there is error in SOAPHandlerInterceptor. I > tried to validate the incoming message in MAPCodec, > there is no BindingOperationInfo set in exchange which stops me to get > the normalized policy. > > > Dan > > > > On Jul 5, 2010, at 4:02 AM, jim ma <mail2ji...@gmail.com> 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...@88e > >> 798 -----------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...@187a > >> b2d > >> > >> # 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...@1669 > >> 79a > >> > >> #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 > > dk...@apache.org > > http://dankulp.com/blog -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
