Re: Server Response Policy

Fri, 08 Aug 2008 09:25:40 -0700

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
[EMAIL PROTECTED]
http://www.dankulp.com/blog

























					Reply via email to