Hi Bruno, I was surprised to get your email so I've tried a similar test with SVN trunk (no change in this area since 5104) and it works just fine. I never get 406 because the conneg algorithm always try to fall-back on one of the variants if it exists.
The test file uses is attached. Regarding annotation values, we can't unfortunately use constant class instances, only primitive types and enumerations... Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -----Message d'origine----- De : news [mailto:n...@ger.gmane.org] De la part de Bruno Harbulot Envoyé : jeudi 18 juin 2009 14:37 À : discuss@restlet.tigris.org Objet : Re: 2.0m3 and content negotiation Hi Jerome, I've just upgraded to revision 5104. (I've have looked in details at the changes in the code.) I'm still not clear what should work with annotations. The simple test-case I'm using tries to do content-type negotiation between text/plain and application/xml. public class TestResource extends ServerResource { @Override public void doInit() throws ResourceException { setNegotiated(true); } @Get("xml") public Representation toXml() { return new OutputRepresentation(MediaType.APPLICATION_XML) { /* ... */ } } } Making a GET request with "Accept: text/plain" produces a "406 Not Acceptable" (which makes sense). However, I get the same error with "Accept: text/xml, application/xml". I do get a successful response (200 with the XML representation intended) with "Accept: */*" (however, there's nothing being negotiated since there's only @Get("xml") here). I believe the problem comes from the fact that ServerResource.getAvailableVariants(...) assumes that 'Representation' implies the media type is going to be application/octet-stream. This example works as intended when declaring the return type to be DomRepresentation instead of Representation: public class TestResource extends ServerResource { @Override public void doInit() throws ResourceException { setNegotiated(true); } @Get("xml") public DomRepresentation toXml() { return /* some DomRepresentation */ } } It seems a bit restrictive not to allow to use Representation and to expect a specific subclass (as there are more potential media types than subclasses of Representation). Regarding the annotation parameters and media types, perhaps it would be useful to allow for both the extension and the actual media types, for example @Get(extension = "txt") and @Get(mediatype = MediaType.TEXT_PLAIN). Best wishes, Bruno. Jerome Louvel wrote: > Hi Bruno, > > Thanks for looking into this part of the code base. > > As said in other emails, many enhancements and refactorings were done > recently on ServerResource, ConverterService and content negotiation. > > Previously, annotation values weren't taken into account, leading to strange > results as you observed. They are now taken into account to result > representation, only media types for now based on extensions declared in > MetadataService. > > The ConverterService has been enhanced to allow better selection of > ConverterHelpers via a scoring logic. Previously, a converter such as > XStream could convert anything to representation and could prevent other > (more specific) converters from being selected. I think that the target > variant is now better taken into account by existing converters. > > Could you have another look at the code and let me know what you think of > the changed recently made? > > Best regards, > Jerome Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23631 56 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2363616
TestServerResource.java
Description: Binary data
