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 21:41:05 GMT
Yeah, I think this summarizes it well.

On Oct 9, 2008, at 5:10 PM, Sergey Beryozkin wrote:

> Hi,
> I'd like to try to summarize what we've talked at this thread. Fred  
> - please
> feel free to challenge what I'm about to say :-)
> Original problem : server-side outbound Policy interceptor assumes  
> that no
> policy alternative has been asserted on the outbound path and  
> reports a
> failure by (mistakenly) writing to the output stream.

Correct -- and in general, this will only happen if there is an  
alternative of cardinality > 1.

> During the discussion (I think/hope :-)) we've mostly agreed that  
> unless
> there's a really strong need for the application to depend upon the  
> out
> verifier failing, this out verifier should do nothing, possibly just  
> logging
> a message and perhaps do nothing at all in most cases.

Correct.  Dan, you: +1 on logging (FINE or lower log level).  Me: +1  
on removing the validation out interceptor (outbound server side  
only), since it's doing nothing put churning cycles and possibly  
confusing the user.

> It's the role of the actual policy interceptors to take stronger  
> action when
> necessary. The role of the verifier is to validate that those  
> interceptors
> have actually done their work. Unless the (out) verifier is given  
> some hints
> about the scope of a given policy expression, it can not reliably  
> assert
> that just because this policy has not been asserted on the outbound  
> path it
> means that the policy contract has not been fulfilled.
> Note that adding such hints only makes sense when it's of paramount
> importance that the out verifier validates that a given policy has  
> been
> engaged on the out path. In other case they're not needed and thus  
> the out
> verifier can keep quiet.
> Only when we do want the out verifier to fail (softly with WARNING  
> or throw
> some exception) then it would make sense adding the hints to the  
> policy
> expressions.
> One way to provide such hint is basically to do a custom  
> implementation of
> PolicyAssertion and return the value based on the custom knowledge
> (similarly to the way interceptors tell about their phases).
> Another idea is to introduce new features to represent inbound or  
> outbound
> only assertions. IMHO this is a bit too coarse-grained and  
> introducing new
> features to represent some qualities of policies (in/out) may not be
> justified. That said this idea may be of help when dealing with  
> tightly
> controlled 3rd party policy expressions (see next).
> Another idea is to introduce a custom attribute, to be added to  
> individual
> policy expressions when needed. There's a concern that it may be too
> intrusive. IMHO the compactness and portability (can be applied to  
> policies
> in the wsdl) of this solution outweighs these concerns.

All three ideas amount to essentially the same idea: that the  
effective policy (hence the policy vocabulary, hence the contents of  
the AssertionInfoMap) is possibly different on the inbound and  
outbound interceptor chains.  /How/ that's done is probably less  
important that /that/ it be done, because I don't think the current  
way is really workable -- Right now I have to hack my way through the  
outbound response AssertionInfoMap, checking off Assertions that have  
already been checked off on the inbound channel, which is a hack  
(requires that I artificially store data on the Exchange, etc), and  
just adds extra overhead to the runtime.


View raw message