cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <f...@dushin.net>
Subject Re: CXF WS-Policy refactoring
Date Sun, 17 Feb 2008 17:50:36 GMT
All good points.

I'd add that we need better config granularity of the PolicyEngine.   
Currently, as I understand it, a PolicyEngine is a Bus extension, so  
it's basically 1-1 on a bus.  That's fine, as a Bus extension.  But  
the PolicyEngine also is the place to configure AlternativeSelectors,  
which you might prefer to have configurable at endpoint granularity  
(or even policy subject granularity, though it's a bit harder to  
imagine how that might work).

The same goes for the PolicyInterceptorProviders and the  
AssertionBuilders -- these are configured per-Bus, as I understand  
it.  But we might want finer-grained config in some cases (E.g., use  
these policy interceptor providers for these endpoints, those for  
another, and yet another set by default).

-Fred

On Jan 29, 2008, at 8:23 AM, Sergey Beryozkin wrote:

> Hi
>
> CXF WS-Policy framework needs a bit of refactoring. While it's  
> already quite sophisticated in what it can do, and some of its  
> features are really cool, like the ability to add JAXB derived  
> assertions, the ability to attach policy expressions externally and  
> inline from Spring using WSPolicyFeature, etc, etc, there're few  
> things which need to be fixed a bit :
> * how various policy subjects contribute to corrresponding effective  
> policies
> * how policy alternatives are selected on the server and on the  
> client (generally a server has to support all the alternatives while  
> the client can select only a single one)
> * automatic policy publication on the server side
> * policy engine needs to be enabled by default, etc...
>
> As such some breaking changes to interfaces like EndpointPolicy  
> (which itself may go in the end, with Policies just keyed by the  
> type of policy subject), PolicyEngine, may need to be applied. CXF  
> does not allow for alternative PolicyEngine or EndpointPolicy  
> implementations be injected anyway. This should not have any adverse  
> affect on any applications out there, if any, which do rely on  
> WSPolicy expressions, perhaps those dealing with WS-Addressing or WS- 
> RM or MTOM...
>
> Cheers, Sergey
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,  
> Ireland


Mime
View raw message