cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <>
Subject Re: More on server response policies
Date Thu, 09 Oct 2008 13:44:18 GMT

On Oct 8, 2008, at 5:16 PM, Sergey Beryozkin wrote:

> Hi
> I agree with what Dan suggested - logging a message in a
> PolicyVerificationOutInterceptor should suffice in most cases. Few  
> more
> comments.
> I think that asserting a policy on the outbound path makes sense  
> only if
> a specification for a given policy expression explicitly states that  
> it
> applies to both inbound and outbound paths or to outbound path only.

Suppose you have this config:

<jaxws:endpoint ...>

Does <foo:Bar> apply to the inbound our outbound path?  Or both?  What  
are the semantics here?

> on the
> server inbound path, a union of all policy expressions is selected  
> as at any
> moment of time we may need to satisfy requests from clients meeting  
> either
> all or one of the available alternatives.
> All required interceptors are
> installed - but the api allows for on-demand interceptors  
> installation (for
> ex, based in the in message's content & headers).

Correct.  Or more appropriately, based on the actual content of the  

> PolicyVerificationInInterceptor would say OK as long as at least one  
> of the
> alternatives is fully satisfied. In your example we have a compact  
> policy
> expression, so there'no problems if either <foo:Bar/> or <gnu:Gnat/>  
> has
> been asserted.
> On the outbound path only the alternative which has been selected  
> during the
> inbound path should be optionally verified. I don't think any  
> alternative
> selection algorithm should apply on the outbound path as we already  
> have an
> alternative active in the scope of a given operation.

That assumes the effective policy is the same on the inbound and  
outbound sides.  I think that's an invalid assumption (as I think you  
are saying, as well).  Or at least I think we should be able to  
discriminate between inbound and outbound policies.  I stand corrected  
in the case of WSDL, but I think we need a way to make the same  
distinction in spring (and however else we retrieve policy).

How about this, for a proposal:

<jaxws:endpoint ...>


<cxf:InboundPolicyFeature>             <!-- new type -->

<cxf:OutboundPolicyFeature>             <!-- new type -->


So on the inbound side you'd get [{foo}Bar, {gnu:Gnat}]

And on the outbound side you'd get [{foo:Bar}, {gnu}Gnat]

> If we have the Ex2
> (above) then this alternative will simply have no any inbound  
> behaviors to
> engage (see more below). In Ex1 - it's up to that specific policy's  
> out
> interceptors to do any additional outbound work.
> Thus, in many cases, like in Ex1, if no explicit out policy  
> interceptors
> have been provided then PolicyVerificationOutInterceptor should  
> simply log a
> (FINE?) level message as suggested. In fact it's not clear what else  
> it can
> do other than do this logging on the server side.

I think this gets us over a hump, but I also think it's kind of a cop- 
out.  Why log anything?  Why even do the check?  What's the purpose,  
if there's no tangible side-effect?  Choke up a log with more garbage?

> While (on the server side) PolicyVerificationInInterceptor is useful  
> in that
> it ensures that at least one alternative has been met, its out  
> counterpart
> is of little use. Unless we provide some hints.

Yup.  If it's of no use, remove it.

> We can introduce additional optional hints (in the form of policy
> attributes) to both in/out verifiers that this policy only applies  
> to the in
> or out path or to both paths. Thus, in case of Ex2, In verifier  
> won't fail
> but Out verifier can log a WARNING (or throw a fault if its phase  
> can be
> changed). Likewise, in Ex3, In verifier may throw exception while OUT
> verifier will keep quiet. In case of Ex1, both in/out verifiers may  
> report
> failures (through exceptions or logging).

Not sure what you mean here.  Attributes on the wsp:Policy elements,  
themselves?  I'd think there'd be a better way to do that, than to add  
proprietary stuff to standard policy expressions.  At any rate, if  
that's what you mean, then I think we should try to avoid it, since it  
won't be in any way interoperable.

> Without such helper attributes the default (server) behavior should  
> likely
> be :
> - PolicyVerificationInInterceptor throws fault if none of the  
> alternatives
> has been met (as it is now)
> - PolicyVerificationOutInterceptor logs a FINE message if not all of  
> the
> expressions in the alternative selected during the inbound  
> invocation has
> been met.

Why?  What possible use is this to the user?  The more I think of it,  
the more I realize the PolicyVerificationOutInterceptor on the  
outbound server side is kind of pointless, especially in light of the  
current bug in its behavior.

I'll reiterate that the API on setting a PolicyAlternativeSelector is  
too coarse -- it's on the PolicyEngine, which is basically in 1-1  
correspondence with the Bus.  I can think of 4 different ways you'd  
want to configure one of these guys (client/server in/out), and you'd  
want to be able to configure that on a per-endpoint basis (at least).


View raw message