>
> 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 <[EMAIL PROTECTED]> 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
