cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <>
Subject Server Response Policy
Date Thu, 07 Aug 2008 19:25:31 GMT

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  

     <jaxws:endpoint ... >
                 <wsp:PolicyReference URI="#MyPolicy"/>
     <wsp:Policy wsu:Id="MyPolicy">

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)	
(PolicyEngineImpl).getEndpointPolicy(EndpointInfo, EndpointPolicy,  
boolean, Assertor) line: 220	
(PolicyEngineImpl).getServerEndpointPolicy(EndpointInfo, Destination)  
line: 214	
BindingOperationInfo, PolicyEngineImpl, boolean) line: 101	
	EffectivePolicyImpl.initialise(EndpointInfo, BindingOperationInfo,  
PolicyEngineImpl, Assertor, boolean) line: 79	
BindingOperationInfo, Destination) line: 171	
	ServerPolicyOutInterceptor.handle(Message) line: 77	
(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	
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	
line: 228	
	SslSocketConnector$ line: 620	
	BoundedThreadPool$ 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  

Note, however, that the SOAP:Fault is actually embedded in the response:

<soap:Envelope xmlns:soap="">
          <sayHiResponse xmlns="">
             <responseType>Bonjour tony</responseType>
              <faultstring>None of the policy alternatives can be  

Oops.  Something seems awry with the phase in which the fault is  

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?


View raw message