Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of sergey.beryozkin@iona.com
 designates 12.170.54.180 as permitted sender)
Message-ID: <003301c86d71$be2dbe20$e002050a@pcgroupiona.com>
From: "Sergey Beryozkin" <sergey.beryozkin@iona.com>
To: <cxf-dev@incubator.apache.org>
References: <6f5a2e920802110523i66b0c414y6a974e5951e7ecd2@mail.gmail.com>
 <002001c86cbe$1cd18ba0$e002050a@pcgroupiona.com>
 <6f5a2e920802110719x1d85e807qadedc9ff1d3a87d9@mail.gmail.com>
 <005a01c86cc7$2e1726a0$e002050a@pcgroupiona.com>
 <009c01c86ccc$9fe8a010$e002050a@pcgroupiona.com>
 <6f5a2e920802120219r70db11e4m353cffff1975ced0@mail.gmail.com>
Subject: Re: JAX-RS Support: Error in the JAX-RS specs for matching method
 types?
Date: Tue, 12 Feb 2008 12:21:06 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0030_01C86D71.BDCE3900"

------=_NextPart_000_0030_01C86D71.BDCE3900
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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,
>=20
> Thanks for asking - no it's not a little annoying but not a blocker.
>=20
> I sent a mail to the JSR-311 users list and they confirmed that my algori=
thm
> is how it is intended to work and they'll rewrite the paragraph to make it
> clearer.
>=20
> I'll raise an issue in JIRA later today.
>=20
> Barry
>=20
> On Feb 11, 2008 4:39 PM, Sergey Beryozkin <sergey.beryozkin@iona.com> wro=
te:
>=20
>> 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 meth=
od
>> 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 meth=
od
>> 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=3D0.9
>> > ,text/plain;q=3D0.8,image/png,*/*;q=3D0.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 a=
re
>> >> 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

------=_NextPart_000_0030_01C86D71.BDCE3900--