You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dan Diephouse <da...@mulesource.com> on 2008/02/01 00:18:24 UTC
Re: CXF WS-Policy refactoring
+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
Re: JAX-RS API version change
Posted by Sergey Beryozkin <se...@iona.com>.
> Well, my comment still stands. Any help adding it to CXF would be
> greatly appreciated. :-)
+1 :-)
Cheers, Sergey
>
>> Client API It's not part of the spec (at the moment). It's something
>> Jersey will provide
>
> Oh. Ok.
>
> Well, my comment still stands. Any help adding it to CXF would be
> greatly appreciated. :-)
>
> Dan
>
>
> On Monday 25 February 2008, Sergey Beryozkin wrote:
>>
>> Cheers, Sergey
>>
>> ----- Original Message -----
>> From: "Daniel Kulp" <dk...@apache.org>
>> To: <cx...@incubator.apache.org>
>> Sent: Monday, February 25, 2008 4:26 PM
>> Subject: Re: JAX-RS API version change
>>
>> > Just to be clear:
>> >> > I do have a question. 0.6 started implementing a REST client API.
>> >> > Does CXF plan to use this Client API or do you suggesting using
>> >> > the HTTP Client used in samples?
>> >
>> > If it's part of the spec, then yes, we do plan on providing it, just
>> > probably not immediately. The server side parts are a bit higher
>> > priority to the folks that are paying us to work on it. :-)
>> >
>> > However, if folks would like to jump in and help, feel free to start
>> > raising jira issues, submit patches, etc.... We'd LOVE to have the
>> > extra help.
>> >
>> > Dan
>> >
>> > On Monday 25 February 2008, Sergey Beryozkin wrote:
>> >> Hi,
>> >>
>> >> > This is cool. Did you update the JAX-RS sample too?
>> >>
>> >> No, will do as part of the next patch, thanks for pointing it out..
>> >>
>> >> > I do have a question. 0.6 started implementing a REST client API.
>> >> > Does CXF plan to use this Client API or do you suggesting using
>> >> > the HTTP Client used in samples?
>> >>
>> >> This is not a priority for CXF JAX-RS at the moment. Yes, that
>> >> Client API looks cool, but I believe it's not something CXF JAX-RS
>> >> users can't live without at this moment of time :-). Things like
>> >> providing a UriInfo implementation, support for types like byte[],
>> >> improving the URITemplating, etc are of higher priority at the
>> >> moment.
>> >>
>> >> > Thank you
>> >> > Arul
>> >>
>> >> Cheers, Sergey
>> >>
>> >> ----------------------------
>> >> IONA Technologies PLC (registered in Ireland)
>> >> Registered Number: 171387
>> >> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
>> >> Ireland
>> >
>> > --
>> > J. Daniel Kulp
>> > Principal Engineer, IONA
>> > dkulp@apache.org
>> > http://www.dankulp.com/blog
>>
>> ----------------------------
>> IONA Technologies PLC (registered in Ireland)
>> Registered Number: 171387
>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
>> Ireland
>
>
>
> --
> J. Daniel Kulp
> Principal Engineer, IONA
> dkulp@apache.org
> http://www.dankulp.com/blog
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: JAX-RS API version change
Posted by Daniel Kulp <dk...@apache.org>.
> Client API It's not part of the spec (at the moment). It's something
> Jersey will provide
Oh. Ok.
Well, my comment still stands. Any help adding it to CXF would be
greatly appreciated. :-)
Dan
On Monday 25 February 2008, Sergey Beryozkin wrote:
>
> Cheers, Sergey
>
> ----- Original Message -----
> From: "Daniel Kulp" <dk...@apache.org>
> To: <cx...@incubator.apache.org>
> Sent: Monday, February 25, 2008 4:26 PM
> Subject: Re: JAX-RS API version change
>
> > Just to be clear:
> >> > I do have a question. 0.6 started implementing a REST client API.
> >> > Does CXF plan to use this Client API or do you suggesting using
> >> > the HTTP Client used in samples?
> >
> > If it's part of the spec, then yes, we do plan on providing it, just
> > probably not immediately. The server side parts are a bit higher
> > priority to the folks that are paying us to work on it. :-)
> >
> > However, if folks would like to jump in and help, feel free to start
> > raising jira issues, submit patches, etc.... We'd LOVE to have the
> > extra help.
> >
> > Dan
> >
> > On Monday 25 February 2008, Sergey Beryozkin wrote:
> >> Hi,
> >>
> >> > This is cool. Did you update the JAX-RS sample too?
> >>
> >> No, will do as part of the next patch, thanks for pointing it out..
> >>
> >> > I do have a question. 0.6 started implementing a REST client API.
> >> > Does CXF plan to use this Client API or do you suggesting using
> >> > the HTTP Client used in samples?
> >>
> >> This is not a priority for CXF JAX-RS at the moment. Yes, that
> >> Client API looks cool, but I believe it's not something CXF JAX-RS
> >> users can't live without at this moment of time :-). Things like
> >> providing a UriInfo implementation, support for types like byte[],
> >> improving the URITemplating, etc are of higher priority at the
> >> moment.
> >>
> >> > Thank you
> >> > Arul
> >>
> >> Cheers, Sergey
> >>
> >> ----------------------------
> >> IONA Technologies PLC (registered in Ireland)
> >> Registered Number: 171387
> >> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> >> Ireland
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer, IONA
> > dkulp@apache.org
> > http://www.dankulp.com/blog
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: JAX-RS API version change
Posted by Sergey Beryozkin <se...@iona.com>.
Client API It's not part of the spec (at the moment). It's something Jersey will provide
Cheers, Sergey
----- Original Message -----
From: "Daniel Kulp" <dk...@apache.org>
To: <cx...@incubator.apache.org>
Sent: Monday, February 25, 2008 4:26 PM
Subject: Re: JAX-RS API version change
>
> Just to be clear:
>
>> > I do have a question. 0.6 started implementing a REST client API.
>> > Does CXF plan to use this Client API or do you suggesting using the
>> > HTTP Client used in samples?
>
> If it's part of the spec, then yes, we do plan on providing it, just
> probably not immediately. The server side parts are a bit higher
> priority to the folks that are paying us to work on it. :-)
>
> However, if folks would like to jump in and help, feel free to start
> raising jira issues, submit patches, etc.... We'd LOVE to have the
> extra help.
>
> Dan
>
>
> On Monday 25 February 2008, Sergey Beryozkin wrote:
>> Hi,
>>
>> > This is cool. Did you update the JAX-RS sample too?
>>
>> No, will do as part of the next patch, thanks for pointing it out..
>>
>> > I do have a question. 0.6 started implementing a REST client API.
>> > Does CXF plan to use this Client API or do you suggesting using the
>> > HTTP Client used in samples?
>>
>> This is not a priority for CXF JAX-RS at the moment. Yes, that Client
>> API looks cool, but I believe it's not something CXF JAX-RS users
>> can't live without at this moment of time :-). Things like providing a
>> UriInfo implementation, support for types like byte[], improving the
>> URITemplating, etc are of higher priority at the moment.
>>
>> > Thank you
>> > Arul
>>
>> Cheers, Sergey
>>
>> ----------------------------
>> IONA Technologies PLC (registered in Ireland)
>> Registered Number: 171387
>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
>> Ireland
>
>
>
> --
> J. Daniel Kulp
> Principal Engineer, IONA
> dkulp@apache.org
> http://www.dankulp.com/blog
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: JAX-RS API version change
Posted by Daniel Kulp <dk...@apache.org>.
Just to be clear:
> > I do have a question. 0.6 started implementing a REST client API.
> > Does CXF plan to use this Client API or do you suggesting using the
> > HTTP Client used in samples?
If it's part of the spec, then yes, we do plan on providing it, just
probably not immediately. The server side parts are a bit higher
priority to the folks that are paying us to work on it. :-)
However, if folks would like to jump in and help, feel free to start
raising jira issues, submit patches, etc.... We'd LOVE to have the
extra help.
Dan
On Monday 25 February 2008, Sergey Beryozkin wrote:
> Hi,
>
> > This is cool. Did you update the JAX-RS sample too?
>
> No, will do as part of the next patch, thanks for pointing it out..
>
> > I do have a question. 0.6 started implementing a REST client API.
> > Does CXF plan to use this Client API or do you suggesting using the
> > HTTP Client used in samples?
>
> This is not a priority for CXF JAX-RS at the moment. Yes, that Client
> API looks cool, but I believe it's not something CXF JAX-RS users
> can't live without at this moment of time :-). Things like providing a
> UriInfo implementation, support for types like byte[], improving the
> URITemplating, etc are of higher priority at the moment.
>
> > Thank you
> > Arul
>
> Cheers, Sergey
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: JAX-RS API version change
Posted by Sergey Beryozkin <se...@iona.com>.
Hi,
>>
> This is cool. Did you update the JAX-RS sample too?
No, will do as part of the next patch, thanks for pointing it out..
> I do have a question. 0.6 started implementing a REST client API. Does
> CXF plan to use this Client API or do you suggesting using the HTTP
> Client used in samples?
This is not a priority for CXF JAX-RS at the moment. Yes, that Client API looks cool, but
I believe it's not something CXF JAX-RS users can't live without at this moment of time :-).
Things like providing a UriInfo implementation, support for types like byte[], improving the URITemplating, etc
are of higher priority at the moment.
>
> Thank you
> Arul
>
Cheers, Sergey
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: JAX-RS API version change
Posted by Arul Dhesiaseelan <ar...@fluxcorp.com>.
Sergey Beryozkin wrote:
> Hi
>
> This update is in place now, so if you're using CXF JAX-RS then please give it a try.
>
> Please note that a newer 0.6 version is already available, and from the user's perspective,
> upgrading to 0.6 will mean that existing @UriParam annotations will need to be replaced with
> @PathParam ones. It seems like the only change in 0.6 which can affect the existing user's code.
> 0.6 jar is not available on Maven yet, so this upgrade will be done a bit later
>
> Cheers, Sergey
>
>
>
> ----- Original Message -----
> From: "Sergey Beryozkin" <se...@iona.com>
> To: <cx...@incubator.apache.org>
> Sent: Friday, February 15, 2008 4:55 PM
> Subject: JAX-RS API version change
>
>
> Hi
>
> Currently, the CXF JAX-RS implementation depend upon a 0.4 version of the jaxrs-api.
> I'm looking into upgrading it to support a latest 0.5 version.
>
> There're some changes from 0.4 to 0.5 which would affect users.
> The following is the list of what has changed between 0.4 and 0.5 which will or may have an effect on the
> current JAX-RS applications built on top of CXF :
>
> 1. @HttpMethod annotation is no longer supported, instead
> @GET, @POST, @PUT and @DELETE annotations will be used
> 2. @UriTemplate is not longer supported, @Path is used instead
>
> 3. EntityProvider interface has gone too, instead it has been split into two interfaces,
> MessageBodyReader and MessageBodyWriter. If you provide custom providers and you'd like to have the same instance to handle both reads and writes, then you'd have to have its class implementing both interfaces.
>
> Existing spring configuration for injecting custom providers won't get changed, the runtime will sort difrerent types of handlers
> into the right lists itself...
>
> Cheers, Sergey
>
>
>
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>
>
This is cool. Did you update the JAX-RS sample too?
I do have a question. 0.6 started implementing a REST client API. Does
CXF plan to use this Client API or do you suggesting using the HTTP
Client used in samples?
Thank you
Arul
Re: JAX-RS API version change
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
This update is in place now, so if you're using CXF JAX-RS then please give it a try.
Please note that a newer 0.6 version is already available, and from the user's perspective,
upgrading to 0.6 will mean that existing @UriParam annotations will need to be replaced with
@PathParam ones. It seems like the only change in 0.6 which can affect the existing user's code.
0.6 jar is not available on Maven yet, so this upgrade will be done a bit later
Cheers, Sergey
----- Original Message -----
From: "Sergey Beryozkin" <se...@iona.com>
To: <cx...@incubator.apache.org>
Sent: Friday, February 15, 2008 4:55 PM
Subject: JAX-RS API version change
Hi
Currently, the CXF JAX-RS implementation depend upon a 0.4 version of the jaxrs-api.
I'm looking into upgrading it to support a latest 0.5 version.
There're some changes from 0.4 to 0.5 which would affect users.
The following is the list of what has changed between 0.4 and 0.5 which will or may have an effect on the
current JAX-RS applications built on top of CXF :
1. @HttpMethod annotation is no longer supported, instead
@GET, @POST, @PUT and @DELETE annotations will be used
2. @UriTemplate is not longer supported, @Path is used instead
3. EntityProvider interface has gone too, instead it has been split into two interfaces,
MessageBodyReader and MessageBodyWriter. If you provide custom providers and you'd like to have the same instance to handle both reads and writes, then you'd have to have its class implementing both interfaces.
Existing spring configuration for injecting custom providers won't get changed, the runtime will sort difrerent types of handlers
into the right lists itself...
Cheers, Sergey
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: JAX-RS API version change
Posted by Sergey Beryozkin <se...@iona.com>.
I've got it mostly finished, but I'm going to add few more tests before supplying a patch
Cheers, Sergey
----- Original Message -----
From: "Sergey Beryozkin" <se...@iona.com>
To: <cx...@incubator.apache.org>
Sent: Friday, February 15, 2008 4:55 PM
Subject: JAX-RS API version change
Hi
Currently, the CXF JAX-RS implementation depend upon a 0.4 version of the jaxrs-api.
I'm looking into upgrading it to support a latest 0.5 version.
There're some changes from 0.4 to 0.5 which would affect users.
The following is the list of what has changed between 0.4 and 0.5 which will or may have an effect on the
current JAX-RS applications built on top of CXF :
1. @HttpMethod annotation is no longer supported, instead
@GET, @POST, @PUT and @DELETE annotations will be used
2. @UriTemplate is not longer supported, @Path is used instead
3. EntityProvider interface has gone too, instead it has been split into two interfaces,
MessageBodyReader and MessageBodyWriter. If you provide custom providers and you'd like to have the same instance to handle both
reads and writes, then you'd have to have its class implementing both interfaces.
Existing spring configuration for injecting custom providers won't get changed, the runtime will sort difrerent types of handlers
into the right lists itself...
Cheers, Sergey
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
JAX-RS API version change
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
Currently, the CXF JAX-RS implementation depend upon a 0.4 version of the jaxrs-api.
I'm looking into upgrading it to support a latest 0.5 version.
There're some changes from 0.4 to 0.5 which would affect users.
The following is the list of what has changed between 0.4 and 0.5 which will or may have an effect on the
current JAX-RS applications built on top of CXF :
1. @HttpMethod annotation is no longer supported, instead
@GET, @POST, @PUT and @DELETE annotations will be used
2. @UriTemplate is not longer supported, @Path is used instead
3. EntityProvider interface has gone too, instead it has been split into two interfaces,
MessageBodyReader and MessageBodyWriter. If you provide custom providers and you'd like to have the same instance to handle both reads and writes, then you'd have to have its class implementing both interfaces.
Existing spring configuration for injecting custom providers won't get changed, the runtime will sort difrerent types of handlers
into the right lists itself...
Cheers, Sergey
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: CXF WS-Policy refactoring
Posted by "Beryozkin, Sergey" <Se...@iona.com>.
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:bharathganesh@gmail.com]
Sent: 15 February 2008 22:00
To: cxf-dev@incubator.apache.org
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
<da...@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
>
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: CXF WS-Policy refactoring
Posted by Bharath Ganesh <bh...@gmail.com>.
>>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 <da...@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
>
>