You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Sergey Beryozkin <se...@iona.com> on 2008/01/29 14:23:45 UTC
CXF WS-Policy refactoring
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
Re: CXF WS-Policy refactoring
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
I'm about to submit the patch which attempts to change the way mutiple policy alternatives
and nested policies are dealt with.There's a number of things which still would need to be refactored and tuned, but some initial refactoring needs to be done anyway.
Currently, policy alternatives are not selected correctly on the server side, that is a single alternative is ever selected,
while in practice, a server should be able to satisfy mutiple alternatives as different clients can choose diffent alternatives.
So the server will support all assertions in all the alternatives by providing all the interceptors needed for a given endpoint.
This is an 'eager' approach, for the types of polices we support at the moment it works just fine, but for more sophisticated
policies, such as those which will come from WS-SecurityPolicy it would not be ideal.
Thus another thing which I've done is I've updated a PolicyInterceptorProvider interface to provide interceptors given a current Message, for ex :
List<Interceptor> provideInInterceptors(Message m);
These methods are delegateing to default get{in/Out}Interceptors() methods for now, but going forward, it would be better for policy interceptor providers to provide interceptors lazily. For ex, AddressingPolicyProvider can check if the message contains
a WSA header and if yes then add MAPAggregator into the chain, etc. Also, at the moment PolicyInterceptorProviders are somehat detached from the actiual Policy instances. I actually think Policy instances should themselevs be Interceptor providers. But it's something we can discuss later.
Another fundmamental change I've done is that now Policy instances are asked 'personally' whether they've been asserted or not :
boolean is Asserted(AssertionInfoMap)
The reason for it is that in the presense of multiple alternatives and especially in the presense of nested Policies, it's really a given Policy instance which can reliably tell whether it has been asserted by checking its nested policies if any, etc, or not.
Thus I had to introduce a PolicyAssertion interface which extends an Apache Neethy Assertion interface.
For ex :
<wsp:Policy>
<!-- Alt 1 -->
<wsp:All>
<sp:TransportBinding>
<wsp:Policy>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:TransportToken>
</sp:TransportToken>
</wsp:Policy>
</sp:TransportBinding>
</wsp:All>
<!-- Alt 2 -->
<wsp:All>
<sp:TransportBinding>
<wsp:Policy>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:TripleDesRsa15/>
</wsp:Policy>
</sp:AlgorithmSuite>
</wsp:Policy>
</sp:TransportBinding>
</wsp:All>
</wsp:Policy>
What does it mean to have a TransportBinding be asserted ? Does it even has to be asserted and may ve only its leaf assertions such as TripleDesRSA15 need to be asserted ? Thus it's better for Assertions themselves to decide.
I've also found that the utility of JAXBAssertions is somewhat limited, they're really suitable for primitive assertions only and one needs to write a utility code on top of them anyway to deal with individual policy data.
There's a number of other refactorings which needs to be done but there're few ones which would be on top of my list :
1. Policies attached through jaxws:endpoints should be published on demand either in WSDL or in EPRs, this issue is blocking few other things.
2. Remove the AlternativeSelectors altogether or refactor them such that they actually work. The problem with them is that they just don't work well. On the server side the idea of selecting a given alternative only is not viable, while on the client side it's not reliable. For ex, on the client side, the runtime should select the alternative which suits the requirements, thus saying that either the 1st one or last one or minimal alternative gets chosen is not a reliable thing to do, a client can be presented with multiple alternatives, with some of them containing assertions with nested Policies with even more alternatives, and it's not feasible to reliably set in advance which alternative should be selected.
3. Policy Intersection so that clients can choose between multiple services dynamically or choose a given alternative based on its own requirements. For ex, if we have a jaxws:client with a policy A and we have a service'WSDL with a policy A and B then A will be selected through the intersection. Using intersection or the current state of the message to choose a given alternative is what clients would ideally do instead of using eager Alternative Selectors.
Cheers, Sergey
> 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
----------------------------
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 Fred Dushin <fr...@dushin.net>.
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
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
>
>
Re: CXF WS-Policy refactoring
Posted by Dan Diephouse <da...@mulesource.com>.
+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