Hi Dave, As I just explained in reply to Tal, your initial issue with POST is now addressed in SVN trunk. Hope this makes sense now what conditional processing is for.
Regarding the support for annotations directly in ServerResource, I initially thought about separating them, but felt that it would be nice to be able to mix both approaches in some cases. In is also easier for somebody to port his existing pre-1.2 resources to the new API and progressively leverage annotations. This isn't fixed in stone though and we have time for refactoring before 1.2 RC. Regarding the lack of documentation and explanation, this is mainly due to the fact that this is still work in progress and the design isn't final yet. The goal of Restlet 1.2 M2 was to get some early feed-back from the community to adjust what needs to be. 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 : David Fogel [mailto:carrotsa...@gmail.com] Envoyé : vendredi 3 avril 2009 07:27 À : discuss@restlet.tigris.org Objet : Re: ServerResource conditional mode Hi Tal- I've been struggling with that very question, as I, too had trouble with POSTing to my new ServerResource subclass. I also noticed that getPreferredVariant(Method.GET) is called during processing of the POST request, and I couldn't figure out why. At first I thought that was the cause of my problems, but it turned out that my problem was in the 2nd time through getPreferredVariant(), in doNegotiatedHandle(), this time called with (the correct) Method.POST. This method was always returning a 406 status - CLIENT_ERROR_NOT_ACCEPTABLE. my post method looked something like this: @Post public void postSomeData(Representation entity) throws ResourceException { .... } the getPreferredVariant code checks the Java return-type of the annotated method, and in this case having a void return type meant that getPreferredVariant returns null, which causes the doNegotiatedHandle to return 406. This doesn't seem like quite the right thing, since it's not clear to me exactly what kind of content negotation can really usefully go on in the (fairly common) case of a POST method which processes Form data and then returns 204- success-no-content. It's also not clear to me whether I should have given the @Post a mediatype value- should this be the incoming representation type of form-url-encoded, or something else? not sure at all. I'd love to see some greater amount of docs or general explanation of what the thinking is here, or else I fear this will cause significant confusion for people... I found it particularly confusing how ServerResource combines support for both annotated and non-annotated subclasses. Maybe support for these two approaches should be broken out into two classes? -Dave Fogel ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=15288 27 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1593013
