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 <[EMAIL PROTECTED]> wrote: > >> Barry, is it a blocker issue for you ? >> >> Cheers, Sergey >> >> ----- Original Message ----- >> From: "Sergey Beryozkin" <[EMAIL PROTECTED]> >> To: <[email protected]> >> 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" <[EMAIL PROTECTED]> >> To: <[email protected]> >> 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 <[EMAIL PROTECTED]> >> 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" <[EMAIL PROTECTED]> >> >> To: <[email protected]> >> >> 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
