cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sergey.beryoz...@iona.com>
Subject Re: JAX-RS Support: Error in the JAX-RS specs for matching method types?
Date Tue, 12 Feb 2008 12:21:06 GMT
Hi Barry

> I'll raise an issue in JIRA later today.

Please do, many thanks for indentifying this issue, and fixing the JSR-311 spec a bit along
the way too :-)

Cheers, Sergey


> Hi Sergey,
> 
> Thanks for asking - no it's not a little annoying but not a blocker.
> 
> I sent a mail to the JSR-311 users list and they confirmed that my algorithm
> is how it is intended to work and they'll rewrite the paragraph to make it
> clearer.
> 
> I'll raise an issue in JIRA later today.
> 
> Barry
> 
> On Feb 11, 2008 4:39 PM, Sergey Beryozkin <sergey.beryozkin@iona.com> wrote:
> 
>> Barry, is it a blocker issue for you ?
>>
>> Cheers, Sergey
>>
>> ----- Original Message -----
>> From: "Sergey Beryozkin" <sergey.beryozkin@iona.com>
>> To: <cxf-dev@incubator.apache.org>
>> Sent: Monday, February 11, 2008 4:00 PM
>> Subject: Re: JAX-RS Support: Error in the JAX-RS specs for matching method
>> types?
>>
>>
>> Hi Barry
>>
>> I'm wondering is it really an error in the spec or is it something our
>> implementation
>> should improve upon ?
>>
>> >   2. Iterate through the accept header list. For each one:
>> >   1. Find all matching methods
>> >      2. If there is only one method return this and break out of the
>> >      accept header loop
>> >      3. If there are multiple methods sort these methods using
>> >      consume mime and produce mime. Then return the first.
>>
>> Looks like this is actually how an algorithm should work anyway.
>> I'm looking at the spec (dated 3rd Oct 2007) and I can see this :
>>
>> "At least one of the acceptable response entity body media types is a
>> supported output format..."
>>
>> Thats' really it, no specifics on how to do the match *between a given
>> accept type's value and a method's produce mime* is given.
>> So, perhaps, the right way is indeed to start from the first Accept value
>> and do sort and everything and pick up the first matching
>> method, if none matches, then go to the next Accept value, if any etc...
>>
>> Looks like we need to have a new JIRA opened :-)
>>
>> Thanks, Sergey
>>
>>
>>
>>
>>
>>
>>
>> ----- Original Message -----
>> From: "Barry Fitzgerald" <barfitzgerald@gmail.com>
>> To: <cxf-dev@incubator.apache.org>
>> Sent: Monday, February 11, 2008 3:19 PM
>> Subject: Re: JAX-RS Support: Error in the JAX-RS specs for matching method
>> types?
>>
>>
>> > Hi Sergey,
>> >
>> > To confirm I don't think this is an error in our implementation - it is
>> an
>> > error on the spec.
>> >
>> >>What happens if you send just "text/xml" for example, will you have
>> getUser
>> > invoked ?
>> >
>> > Yes, the correct method will be invoked.
>> >
>> > The problem is the steps in the alogrithm. Simply choosing all possible
>> > methods and then sorting these according to their produce and consume
>> Mimes
>> > will not work.
>> >
>> > A correct algorithm would:
>> >
>> >   1. Sort the Accept header according to the W3 standards
>> >   2. Iterate through the accept header list. For each one:
>> >   1. Find all matching methods
>> >      2. If there is only one method return this and break out of the
>> >      accept header loop
>> >      3. If there are multiple methods sort these methods using
>> >      consume mime and produce mime. Then return the first.
>> >
>> > Therefore when accept header of "text/xml, text/*, */*" is sent in.
>> Methods
>> > matching "text/html" are first searched for then "text/*" then "*/*". I
>> > think this would solve the problem.
>> >
>> > This isn't some arbitrary obscure scenario.
>> >
>> > Looking at firefox's defaults it sends
>> > "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9
>> > ,text/plain;q=0.8,image/png,*/*;q=0.5"
>> >
>> > Surely for a request from firefox I'd expect to get back one of the
>> stated
>> > accepts not "application/widget" or "application/json"?
>> >
>> > Barry
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Feb 11, 2008 2:55 PM, Sergey Beryozkin <sergey.beryozkin@iona.com>
>> wrote:
>> >
>> >> Hi Barry
>> >>
>> >> You're sending Accept "text/xml,*/*",
>> >> and thus I believe a method annotated with application/json is also
>> picked
>> >> up.
>> >>
>> >> I agree that perhpas in this case a text/xml needs to be invoked, but
>> how
>> >> the algorithm needs to be changed ?
>> >>
>> >> */* matches both methods, thus both methods are picked up.
>> >> But what happens next ? If we just have to accept types as in your
>> case,
>> >> then using text/xml as a key one could pick up the right method, but
>> what if
>> >> we have "application/json, text/xml,*/*" ?
>> >>
>> >> What happens if you send just "text/xml" for example, will you have
>> >> getUser invoked ?
>> >>
>> >> Cheers, Sergey
>> >>
>> >>
>> >>
>> >> ----- Original Message -----
>> >> From: "Barry Fitzgerald" <barfitzgerald@gmail.com>
>> >> To: <cxf-dev@incubator.apache.org>
>> >> Sent: Monday, February 11, 2008 1:23 PM
>> >> Subject: JAX-RS Support: Error in the JAX-RS specs for matching method
>> >> types?
>> >>
>> >>
>> >> > Hi all,
>> >> >
>> >> > I think there is an error in the algorithm in the JAX-RS specs for
>> >> choosing
>> >> > the resource method (see bullet 2. in section 2.6)
>> >> >
>> >> > Consider the following scenario:
>> >> >
>> >> > I have a resource with 2 methods:
>> >> >
>> >> > @HttpMethod("GET")
>> >> > @UriTemplate("/users/{id}")
>> >> > @ProduceMime("text/xml")
>> >> > public Response getUser(@UriParam("id") String id) throws Exception
{
>> >> ....}
>> >> >
>> >> > @HttpMethod("GET")
>> >> > @UriTemplate("/users/{id}")
>> >> > @ProduceMime("application/json")
>> >> > public Response getUserJSON(@UriParam("id") String id) throws
>> Exception
>> >> {
>> >> > ....}
>> >> >
>> >> > If I then send a request to /users/24 with Accept headers of
>>  "text/xml,
>> >> > */*" one would expect the "text/xml" method to be invoked. However
>> >> following
>> >> > the algorithm in the spec it is undefined which method should be
>> >> invoked.
>> >> >
>> >> > More details:
>> >> >
>> >> > In the algorithm, both methods match the accept headers i.e. they are
>> >> both
>> >> > added to the list of "matching resource methods" This list is then
>> >> sorted
>> >> > using the consume mime type (not relevant in this case) and then by
>> the
>> >> > produce mime. In this case it will compare "text/xml" against
>> >> > "application/json". As both are equally specific it is undefined
>> which
>> >> > should be first. (The current version of CXF trunk sorts
>> >> application/json to
>> >> > the top of the list)
>> >> >
>> >> > However surely as the "text/xml" method matches the accept header
>> >> > specifically it should always be returned first? See -
>> >> > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html for further
>> >> details
>> >> >
>> >> > I think this is an error in the spec (not how it's been implemented
>> in
>> >> CXF).
>> >> >
>> >> >
>> >> > Can anyone confirm if I've made any mistakes in my reasoning?
>> >> >
>> >> > Barry
>> >> >
>> >>
>> >> ----------------------------
>> >> 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
>>
>> ----------------------------
>> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message