cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Barry Fitzgerald" <barfitzger...@gmail.com>
Subject Re: JAX-RS Support: Error in the JAX-RS specs for matching method types?
Date Wed, 13 Feb 2008 12:15:27 GMT
Issue raised: https://issues.apache.org/jira/browse/CXF-1431


On Feb 12, 2008 12:21 PM, Sergey Beryozkin <sergey.beryozkin@iona.com>
wrote:

> 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