cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <f...@dushin.net>
Subject Re: Server Response Policy
Date Fri, 08 Aug 2008 16:24:28 GMT
Well I can definitely work around the problem, just by configuring my  
interceptors to check off the same assertions on the outbound side.   
This requires though, that I stick a reference to some request state  
information on the exchange, and that I ensure that an OutInterceptor  
is installed before between the policy interceptors on the outbound  
side.

My solution seems a little hokey to me -- I'd rather that the  
AssertionInfo objects I've already ticked off as asserted be the same  
instances on the response channel, but that's not the case (I have not  
looked yet to see where a copy of the AssertionInfoMap is made --  
maybe that's the real issue here, as opposed to the same effective  
policy on the inbound and outbound sides).

-Fred

On Aug 8, 2008, at 11:55 AM, Daniel Kulp wrote:

> 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
> dkulp@apache.org
> http://www.dankulp.com/blog
>


Mime
View raw message