I'm slowly progressing on some of the WS-Policy refactoring, as I'm splitting this work with some other CXF work. Yes, it's a good idea to enable a PolicyEngine automatically, I agree. Lets discuss it a bit further. Do you reckon it should be enabled on the first endpoint with Policies extensions being deployed ?
I was thinking it should be done a bit earlier, when seeing the first policy extension added either through a spring config or from a wsdl Cheers, Sergey -----Original Message----- From: Bharath Ganesh [mailto:[EMAIL PROTECTED] Sent: 15 February 2008 22:00 To: [email protected] Subject: Re: CXF WS-Policy refactoring >>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 <[EMAIL PROTECTED]> 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 > > ---------------------------- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
