cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sergey.beryoz...@iona.com>
Subject Re: Server Response Policy
Date Fri, 22 Aug 2008 14:43:42 GMT
Hi

I reckon it would be useful if it were possible to explicitly state in the CXF WS-Policy feature
that a given policy
expression is inbound/outbound only.
Perhaps another option is to provide reusable policy interceptors which could simply (and
blindly) assert some policies using 
preconfigured custom policy namespaces (ex : get an AssertionInfo matching a configured policy
namespace and assert it), such that 
such interceptors can be reused in cases whereby it does not make much sense to enforce some
policies on the inbound or outbound 
chain...

Cheers, Sergey

> 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
>> 

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Mime
View raw message