Hmm.. I'm not really sure, but this MAY be correct behavior. I'm thinking something like the MTOM policy. For that, there has to be something on the outgoing side to see if the MTOM policy is there and turn on MTOM if so.
It's somewhat like some policies are "enforced" on the incoming chain, and "configured" on the outgoing chains. Thus, the policy should be able to handle both sides of that. Dan On Thursday 07 August 2008 3:25:31 pm Fred Dushin wrote: > I'm having trouble with the CXF policy framework, which is causing a > little bit of grief. I think this is a developer, as opposed to a > user issue, as I /think/ it points to a bug in the policy framework. > If not, I can migrate the conversation to the users list. > > What I'm finding is that a CXF server that has policy defined at the > endpoint (I'm using the CXF policy feature, whereby you can reference > a WS-Policy expression in Spring) is effectively treating the > operative policy in the server on the outbound interceptor chain the > same way as it does on the inbound interceptor chain. > > Let me be more concrete. Assume the following config fragment in > Spring: > > <jaxws:endpoint ... > > <jaxws:features> > <cxfp:policies> > <wsp:PolicyReference URI="#MyPolicy"/> > </cxfp:policies> > </jaxws:features> > </jaxws:endpoint> > ... > <wsp:Policy wsu:Id="MyPolicy"> > ... > </wsp:Policy> > > So on the inbound server side, I definitely get this as the effective > policy, and I can do policy enforcement by setting the asserted flag > on various assertions selected (in the case of inbound server, > everything is selected). Note that I have interceptors installed in > the runtime to do this enforcement. > > However, on the outbound response, I'm getting the same effective > policy, and I can see how it's getting set -- precisely in the > following stacktrace (pardon the wrap): > > Thread [btpool2-1] (Suspended) > > InitializingPolicyEngine > (PolicyEngineImpl).getEndpointPolicy(EndpointInfo, EndpointPolicy, > boolean, Assertor) line: 220 > > InitializingPolicyEngine > (PolicyEngineImpl).getServerEndpointPolicy(EndpointInfo, Destination) > line: 214 > EffectivePolicyImpl.initialisePolicy(EndpointInfo, > BindingOperationInfo, PolicyEngineImpl, boolean) line: 101 > EffectivePolicyImpl.initialise(EndpointInfo, BindingOperationInfo, > PolicyEngineImpl, Assertor, boolean) line: 79 > > InitializingPolicyEngine > (PolicyEngineImpl).getEffectiveServerResponsePolicy(EndpointInfo, > BindingOperationInfo, Destination) line: 171 > ServerPolicyOutInterceptor.handle(Message) line: 77 > > ServerPolicyOutInterceptor > (AbstractPolicyInterceptor).handleMessage(Message) line: 56 > PhaseInterceptorChain.doIntercept(Message) line: 221 > OutgoingChainInterceptor.handleMessage(Message) line: 74 > PhaseInterceptorChain.doIntercept(Message) line: 221 > ChainInitiationObserver.onMessage(Message) line: 78 > JettyHTTPDestination.serviceRequest(ServletContext, > HttpServletRequest, HttpServletResponse) line: 278 > JettyHTTPDestination.doService(ServletContext, HttpServletRequest, > HttpServletResponse) line: 252 > JettyHTTPHandler.handle(String, HttpServletRequest, > HttpServletResponse, int) line: 70 > ContextHandler.handle(String, HttpServletRequest, > HttpServletResponse, int) line: 726 > ContextHandlerCollection.handle(String, HttpServletRequest, > HttpServletResponse, int) line: 206 > Server(HandlerWrapper).handle(String, HttpServletRequest, > HttpServletResponse, int) line: 152 > Server.handle(HttpConnection) line: 324 > HttpConnection.handleRequest() line: 505 > HttpConnection$RequestHandler.content(Buffer) line: 842 > HttpParser.parseNext() line: 730 > HttpParser.parseAvailable() line: 205 > HttpConnection.handle() line: 380 > SslSocketConnector$SslConnection(SocketConnector$Connection).run() > line: 228 > SslSocketConnector$SslConnection.run() line: 620 > BoundedThreadPool$PoolThread.run() line: 450 > > But in this case, there are no interceptors installed in the response > interceptor chain. As a consequence, the request "fails" (in a manner > described below) with a "None of the policy alternatives can be > satisfied" message, which is set in the > PolicyVerificationOutInterceptor. > > Note, however, that the SOAP:Fault is actually embedded in the response: > > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> > <soap:Body> > <sayHiResponse xmlns="http://acme.com/greeter/types";> > <responseType>Bonjour tony</responseType> > </sayHiResponse> > <soap:Fault> > <faultcode>soap:Server</faultcode> > <faultstring>None of the policy alternatives can be > satisfied.</faultstring> > </soap:Fault> > </soap:Body> > </soap:Envelope> > > Oops. Something seems awry with the phase in which the fault is > written. > > But regardless, should the effective policy on the response be the > same as the effective policy on the request? Or should policy > assertion implementors code their interceptors to handle the response > chain, as well as the request? > > -Fred -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
