cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bharath Ganesh" <bharathgan...@gmail.com>
Subject Re: CXF WS-Policy refactoring
Date Fri, 15 Feb 2008 22:00:14 GMT
>>policy engine needs to be enabled by default, etc...
I am a bit concerned about this. The Policy Engine implementation is quite
heavy now. If you look at the current implementation, irrespective of
whether the endpoint has a policy associated or not, certain data structures
are always populated (at both client and server side).
I have a patch to enable policy engine only on deployment of first endpoint
containing a WS-Policy assertion. (same on client side - on creation of
servicedelegate).




On Fri, Feb 1, 2008 at 4:48 AM, Dan Diephouse <dan.diephouse@mulesource.com>
wrote:

> +1 to fixing all these things. It definitely needs a combing over. I'm
> completely OK with breaking the Policy APIs.
>
> Some things to keep in mind while refactoring:
> 1. IIRC, its still only possible to use one policy version across the
> whole runtime. Seems like a bad limitation.
> 2. There is no support for global polices which are enforced across all
> servers. I tried figuring this out one day but got completely lost in
> the code. :-(
> 3. Along the lines of #2, WSPolicyFeature.initialize(Bus) doesn't do the
> right thing.
>
> Good luck and I'll be happy to test stuff out down the road :-)
>
> - Dan
>
> 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
> >
> >
>
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message