You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Philipp Leitner <xp...@gmx.at> on 2008/07/02 11:01:15 UTC
JAX-RS Path Precedence
Hi all,
I have a seemingly simple JAX-RS question, but, for some reason, I
cannot figure it out.
Assume a simple REST order service.
GET /order should return a list of all current orders, while
GET /order/{id} should return the details of the order with the id {id}.
How would I annotate this in JAX-RS / CXF? My simple approach
<snip>
@Path("/")
public class OrderService {
@GET
@Path(value="/order", limited=true)
public List<Order> getOrders() {
....
}
@GET
@Path(value="/order/{id}", limited=true)
public Order getOrder(@PathParam("id") String id) {
....
}
}
</snip>
does not seem to work, because the mapping '/order/{id}' seems to
match both request types from above (and I get a NPE for GET /order).
Why is this the case? To me this behavior seems counter-intuitive,
since intuitively @Path(value="/order") seems like a 'better' match
for GET /order than @Path(value="/order/{id}") ...
Can somebody please shed a light on this?
/philipp
Re: JAX-RS Path Precedence
Posted by Brice <br...@gmail.com>.
>
> However, let me gratulate you guys for the JAX-RS implementation in CXF :)
> So far, I had a very enjoyable time working with it. I think this could
> finally be what makes RESTful services the real deal in enterprise
> computing.
>
Fully agreeing on that matter, event if there's still some catch, I still
think CXF has a very very good potential :)
On Wed, Jul 2, 2008 at 15:48, Philipp Leitner <xp...@gmx.at> wrote:
> Sergey,
>
> sorry, I was not aware that this has already been discussed before. I think
> I am unable to check out the latest trunk for the time being, but I will
> check the next release for your fix (and see if the NPE goes away). As for
> the List<Order> ... yes, I have already figured out that JAXB does not work
> this way, and changed my implementation to return an 'OrderList', which is a
> simple JavaBean wrapper for a List<Order> (similar to the one example you
> have online).
>
> However, let me gratulate you guys for the JAX-RS implementation in CXF :)
> So far, I had a very enjoyable time working with it. I think this could
> finally be what makes RESTful services the real deal in enterprise
> computing.
>
> all the best,
> philipp
>
>
> On Jul 2, 2008, at 2:07 PM, Sergey Beryozkin wrote:
>
> Hi
>>
>> I think this is what Brad has hit earlier. Typically selection between
>> otherwise similar methods is driven by the number of
>> discriminators, such as produce/consume mime types, etc, but in this case
>> all of them but the path values match. As a result of the
>> feedback based on the Brad's example, the JAX-RS specification will update
>> the way path expressions are converted into regular ones.
>> The latest code on the trunk fixes this issue using a temporarily
>> workaround (precedence based on a number of matching groups).
>>
>> @GET
>>> @Path(value="/order", limited=true)
>>> public List<Order> getOrders() {
>>> ....
>>> }
>>>
>>
>> I hope the NPE will go away too on the latest trunk. The issue here is
>> that no out-of the box providers support the serialization of
>> collections such as List. The updated JAXB Provider will check for the
>> ObjectFactory if any available in Order's java package (I
>> think I was able to get to the generic type of response element at
>> runtime...) - perhaps you can use JAXBElements in that factory or
>> indeed you can use JAXBElement in your signature if it's acceptable.
>> JAXBProvider also checks for @XmlJavaTypeAdapter on a method for
>> marshalling only - this is another thing you can try - at some
>> stage such adapters will probably get created automatically...
>>
>> Cheers, Sergey
>>
>> Hi all,
>>>
>>> I have a seemingly simple JAX-RS question, but, for some reason, I
>>> cannot figure it out.
>>>
>>> Assume a simple REST order service.
>>>
>>> GET /order should return a list of all current orders, while
>>> GET /order/{id} should return the details of the order with the id {id}.
>>>
>>> How would I annotate this in JAX-RS / CXF? My simple approach
>>>
>>> <snip>
>>>
>>> @Path("/")
>>> public class OrderService {
>>>
>>> @GET
>>> @Path(value="/order", limited=true)
>>> public List<Order> getOrders() {
>>> ....
>>> }
>>>
>>> @GET
>>> @Path(value="/order/{id}", limited=true)
>>> public Order getOrder(@PathParam("id") String id) {
>>> ....
>>> }
>>>
>>> }
>>>
>>> </snip>
>>>
>>> does not seem to work, because the mapping '/order/{id}' seems to match
>>> both request types from above (and I get a NPE for GET
>>> /order). Why is this the case? To me this behavior seems
>>> counter-intuitive, since intuitively @Path(value="/order") seems like a
>>> 'better' match for GET /order than @Path(value="/order/{id}") ...
>>>
>>> Can somebody please shed a light on this?
>>>
>>> /philipp
>>>
>>
>> ----------------------------
>> IONA Technologies PLC (registered in Ireland)
>> Registered Number: 171387
>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>>
>
>
--
Bryce
Re: JAX-RS Path Precedence
Posted by Philipp Leitner <xp...@gmx.at>.
'That's another solution, yes. I think that NPE in your version of
CXF is actually caused by the fact no provider has been found for
List<Order>...'
True. That NPE is gone, however, not that original problem that
getOrder(Order o) is invoked when getOrder() should be.
I will check out the next release and check again there.
Thanks again,
/philipp
On Jul 2, 2008, at 4:29 PM, Sergey Beryozkin wrote:
> Hi Philipp
>
>
>> Sergey,
>>
>> sorry, I was not aware that this has already been discussed before.
>> I think I am unable to check out the latest trunk for the
>> time being, but I will check the next release for your fix (and
>> see if the NPE goes away). As for the List<Order> ... yes, I
>> have already figured out that JAXB does not work this way, and
>> changed my implementation to return an 'OrderList', which is a
>> simple JavaBean wrapper for a List<Order> (similar to the one
>> example you have online).
>
> That's another solution, yes. I think that NPE in your version of
> CXF is actually caused by the fact no
> provider has been found for List<Order>...
>>
>> However, let me gratulate you guys for the JAX-RS implementation
>> in CXF :) So far, I had a very enjoyable time working with it. I
>> think this could finally be what makes RESTful services the real
>> deal in enterprise computing.
>
> Many thanks. I think the credits should actually go to the people
> behind JAX-RS.
> Be aware though that the current CXF JAX-RS is far from the ideal
> state yet (even after the latest update) compared to good
> implementations like Jersey, so don't be surprized if you hit few
> more NPEs :-)
> As for the RESTful services and enterprise computing I hope CXF can
> be a pretty good platform to play with due to its top-class JAX-WS
> support and now due its capability to support JAX-RS services too -
> there could be some interesting combinations there ('mix and match'
> of JAX-WS and JAX-RS - I'm of opinion that both paradigms can live
> well together, etc...).
>
> Cheers, Sergey
>
>>
>> all the best,
>> philipp
>>
>
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
Re: JAX-RS Path Precedence
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Philipp
> Sergey,
>
> sorry, I was not aware that this has already been discussed before. I think I am unable to check out the latest trunk for the
> time being, but I will check the next release for your fix (and see if the NPE goes away). As for the List<Order> ... yes, I
> have already figured out that JAXB does not work this way, and changed my implementation to return an 'OrderList', which is a
> simple JavaBean wrapper for a List<Order> (similar to the one example you have online).
That's another solution, yes. I think that NPE in your version of CXF is actually caused by the fact no
provider has been found for List<Order>...
>
> However, let me gratulate you guys for the JAX-RS implementation in CXF :) So far, I had a very enjoyable time working with it. I
> think this could finally be what makes RESTful services the real deal in enterprise computing.
Many thanks. I think the credits should actually go to the people behind JAX-RS.
Be aware though that the current CXF JAX-RS is far from the ideal state yet (even after the latest update) compared to good
implementations like Jersey, so don't be surprized if you hit few more NPEs :-)
As for the RESTful services and enterprise computing I hope CXF can be a pretty good platform to play with due to its top-class
JAX-WS support and now due its capability to support JAX-RS services too - there could be some interesting combinations there ('mix
and match' of JAX-WS and JAX-RS - I'm of opinion that both paradigms can live well together, etc...).
Cheers, Sergey
>
> all the best,
> philipp
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: JAX-RS Path Precedence
Posted by Philipp Leitner <xp...@gmx.at>.
Sergey,
sorry, I was not aware that this has already been discussed before. I
think I am unable to check out the latest trunk for the time being,
but I will check the next release for your fix (and see if the NPE
goes away). As for the List<Order> ... yes, I have already figured out
that JAXB does not work this way, and changed my implementation to
return an 'OrderList', which is a simple JavaBean wrapper for a
List<Order> (similar to the one example you have online).
However, let me gratulate you guys for the JAX-RS implementation in
CXF :) So far, I had a very enjoyable time working with it. I think
this could finally be what makes RESTful services the real deal in
enterprise computing.
all the best,
philipp
On Jul 2, 2008, at 2:07 PM, Sergey Beryozkin wrote:
> Hi
>
> I think this is what Brad has hit earlier. Typically selection
> between otherwise similar methods is driven by the number of
> discriminators, such as produce/consume mime types, etc, but in this
> case all of them but the path values match. As a result of the
> feedback based on the Brad's example, the JAX-RS specification will
> update the way path expressions are converted into regular ones.
> The latest code on the trunk fixes this issue using a temporarily
> workaround (precedence based on a number of matching groups).
>
>> @GET
>> @Path(value="/order", limited=true)
>> public List<Order> getOrders() {
>> ....
>> }
>
> I hope the NPE will go away too on the latest trunk. The issue here
> is that no out-of the box providers support the serialization of
> collections such as List. The updated JAXB Provider will check for
> the ObjectFactory if any available in Order's java package (I
> think I was able to get to the generic type of response element at
> runtime...) - perhaps you can use JAXBElements in that factory or
> indeed you can use JAXBElement in your signature if it's acceptable.
> JAXBProvider also checks for @XmlJavaTypeAdapter on a method for
> marshalling only - this is another thing you can try - at some
> stage such adapters will probably get created automatically...
>
> Cheers, Sergey
>
>> Hi all,
>>
>> I have a seemingly simple JAX-RS question, but, for some reason, I
>> cannot figure it out.
>>
>> Assume a simple REST order service.
>>
>> GET /order should return a list of all current orders, while
>> GET /order/{id} should return the details of the order with the id
>> {id}.
>>
>> How would I annotate this in JAX-RS / CXF? My simple approach
>>
>> <snip>
>>
>> @Path("/")
>> public class OrderService {
>>
>> @GET
>> @Path(value="/order", limited=true)
>> public List<Order> getOrders() {
>> ....
>> }
>>
>> @GET
>> @Path(value="/order/{id}", limited=true)
>> public Order getOrder(@PathParam("id") String id) {
>> ....
>> }
>>
>> }
>>
>> </snip>
>>
>> does not seem to work, because the mapping '/order/{id}' seems to
>> match both request types from above (and I get a NPE for GET
>> /order). Why is this the case? To me this behavior seems counter-
>> intuitive, since intuitively @Path(value="/order") seems like a
>> 'better' match for GET /order than @Path(value="/order/{id}") ...
>>
>> Can somebody please shed a light on this?
>>
>> /philipp
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
Re: JAX-RS Path Precedence
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
I think this is what Brad has hit earlier. Typically selection between otherwise similar methods is driven by the number of
discriminators, such as produce/consume mime types, etc, but in this case all of them but the path values match. As a result of the
feedback based on the Brad's example, the JAX-RS specification will update the way path expressions are converted into regular ones.
The latest code on the trunk fixes this issue using a temporarily workaround (precedence based on a number of matching groups).
> @GET
> @Path(value="/order", limited=true)
> public List<Order> getOrders() {
> ....
> }
I hope the NPE will go away too on the latest trunk. The issue here is that no out-of the box providers support the serialization of
collections such as List. The updated JAXB Provider will check for the ObjectFactory if any available in Order's java package (I
think I was able to get to the generic type of response element at runtime...) - perhaps you can use JAXBElements in that factory or
indeed you can use JAXBElement in your signature if it's acceptable.
JAXBProvider also checks for @XmlJavaTypeAdapter on a method for marshalling only - this is another thing you can try - at some
stage such adapters will probably get created automatically...
Cheers, Sergey
> Hi all,
>
> I have a seemingly simple JAX-RS question, but, for some reason, I cannot figure it out.
>
> Assume a simple REST order service.
>
> GET /order should return a list of all current orders, while
> GET /order/{id} should return the details of the order with the id {id}.
>
> How would I annotate this in JAX-RS / CXF? My simple approach
>
> <snip>
>
> @Path("/")
> public class OrderService {
>
> @GET
> @Path(value="/order", limited=true)
> public List<Order> getOrders() {
> ....
> }
>
> @GET
> @Path(value="/order/{id}", limited=true)
> public Order getOrder(@PathParam("id") String id) {
> ....
> }
>
> }
>
> </snip>
>
> does not seem to work, because the mapping '/order/{id}' seems to match both request types from above (and I get a NPE for GET
> /order). Why is this the case? To me this behavior seems counter-intuitive, since intuitively @Path(value="/order") seems like a
> 'better' match for GET /order than @Path(value="/order/{id}") ...
>
> Can somebody please shed a light on this?
>
> /philipp
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland