Re: Re: Restlet 2.0 M3 released
There is a wonderful free gift waiting for you! http://www.salontshirts.com/salontshirts/catalog/coupons/bestsellers.html 2009/6/17, Jerome Louvel jerome.lou...@noelios.com: Hello Rémi, Thanks as always for your feed-back. Do you think that your issue regarding the media type returned is a bug from our conneg algorithm? What is the Java class that your annotated method returns? Do you have an annotation value? Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com De : remidewi...@gmail.com [mailto:remidewi...@gmail.com] De la part de Rémi Dewitte Envoyé : mercredi 17 juin 2009 16:18 À : discuss@restlet.tigris.org Objet : Re: Restlet 2.0 M3 released Hello, I had an issue with the new scoring algorithm and jQuery and FF because some of my resources were returning not the same mime type as it used to. Returning application/xhtml+xml causes a document node instead of a div DOM element to be created in FF. And an JS error while trying an append. Otherwise everthing is going smoothly ! Thanks, Rémi On Tue, Jun 16, 2009 at 23:31, Tal Liron tal.li...@threecrickets.com wrote: Oops! That#39;s what I meant! (not VariantInfo) Rob Heittman wrote: And 4. that new RepresentationInfo thing is pure nitroglycerine. Thanks for validating trunk, Tal, I had to hold off on some port attempts on my end due to the 406 problem ... I#39;ll give it another whirl. On Tue, Jun 16, 2009 at 2:30 PM, Tal Liron tal.li...@threecrickets.com mailto:tal.li...@threecrickets.com wrote: 1. Routing: Routing seems to be being reworked. I#39;m not sure how it will look for the final release as of yet, but the RFEs point to some very useful abilities. 2. High-level HTTP: ServerResource is a revolution in this regard. Annotations will allow a very concise way of defining the rules for negotiation. And the advent VariantInfo class (with the getInfo methods) can really improve performance for negotiation. (I#39;m think there should be a tutorial to show this in action.) 3. Representation: The advent of the ConverterService makes it easy to handle transformations across the entire application/service. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2362613 dsMessageId=2362613 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2362910 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2714257
Re: Restlet 2.0 M3 released
And 4. that new RepresentationInfo thing is pure nitroglycerine. Thanks for validating trunk, Tal, I had to hold off on some port attempts on my end due to the 406 problem ... I'll give it another whirl. On Tue, Jun 16, 2009 at 2:30 PM, Tal Liron tal.li...@threecrickets.comwrote: 1. Routing: Routing seems to be being reworked. I'm not sure how it will look for the final release as of yet, but the RFEs point to some very useful abilities. 2. High-level HTTP: ServerResource is a revolution in this regard. Annotations will allow a very concise way of defining the rules for negotiation. And the advent VariantInfo class (with the getInfo methods) can really improve performance for negotiation. (I'm think there should be a tutorial to show this in action.) 3. Representation: The advent of the ConverterService makes it easy to handle transformations across the entire application/service. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2362566
RE: Restlet 2.0 M3 released
Thanks Tal and Rob for your positive feed-back. The latest round of enhancements has allowed great internal refactorings as well (see Metadata#getParent(), includes(), isCompatible(), Variant, Directory, etc.). Directory has been optimized as well for some specific case, when a file can directly be matched, without having anymore to list the directory content (I havent tested it with the WAR client, but I suspect nice performance boost there as well)! Like you, Im very happy to see how ServerResource is coming along and allowing us to streamline our code base for better HTTP support! I feel like Restlet 1.x releases allowed us to lay great foundations (routing, representations, containers, connectors, etc.) and experiment with the concept of higher level resource classes (via Resource). Restlet 2.0 should really get this higher-level part done right (UniformResource), with some nice inspiration from the JAX-RS annotation experience. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com De : Rob Heittman [mailto:rob.heitt...@solertium.com] Envoyé : mardi 16 juin 2009 21:21 À : discuss@restlet.tigris.org Objet : Re: Restlet 2.0 M3 released And 4. that new RepresentationInfo thing is pure nitroglycerine. Thanks for validating trunk, Tal, I had to hold off on some port attempts on my end due to the 406 problem ... I'll give it another whirl. On Tue, Jun 16, 2009 at 2:30 PM, Tal Liron tal.li...@threecrickets.com wrote: 1. Routing: Routing seems to be being reworked. I'm not sure how it will look for the final release as of yet, but the RFEs point to some very useful abilities. 2. High-level HTTP: ServerResource is a revolution in this regard. Annotations will allow a very concise way of defining the rules for negotiation. And the advent VariantInfo class (with the getInfo methods) can really improve performance for negotiation. (I'm think there should be a tutorial to show this in action.) 3. Representation: The advent of the ConverterService makes it easy to handle transformations across the entire application/service. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2362583
Re: Restlet 2.0 M3 released
Oops! That's what I meant! (not VariantInfo) Rob Heittman wrote: And 4. that new RepresentationInfo thing is pure nitroglycerine. Thanks for validating trunk, Tal, I had to hold off on some port attempts on my end due to the 406 problem ... I'll give it another whirl. On Tue, Jun 16, 2009 at 2:30 PM, Tal Liron tal.li...@threecrickets.com mailto:tal.li...@threecrickets.com wrote: 1. Routing: Routing seems to be being reworked. I'm not sure how it will look for the final release as of yet, but the RFEs point to some very useful abilities. 2. High-level HTTP: ServerResource is a revolution in this regard. Annotations will allow a very concise way of defining the rules for negotiation. And the advent VariantInfo class (with the getInfo methods) can really improve performance for negotiation. (I'm think there should be a tutorial to show this in action.) 3. Representation: The advent of the ConverterService makes it easy to handle transformations across the entire application/service. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2362613
RE: Restlet 2.0 M3 released
Hi Tal, This should now be fixed in SVN trunk. Could you confirm? 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 : Tal Liron [mailto:tal.li...@threecrickets.com] Envoyé : mercredi 3 juin 2009 08:54 À : discuss@restlet.tigris.org Objet : Re: Restlet 2.0 M3 released To add to this -- It seems that something changed with how negotiated mode is handled. It's breaking not just Directory, but also some of my other ServerResources. With my resources, I found that setNegotiated(false) fixed the problem, so I'm guessing that the bug introduced is somewhere there. Should we open an issue for this in Tigris? -Tal Matt wrote: Hi Jerome, I'll put together some sample code highlighting this issue for you. Cheers, Matt jlouvel wrote: Matt, I've just done a simple test with Directory and SVN trunk and I'm able to serve static files fine. I guess something else is causing an issue. We did migrate the Directory and its internal DirectoryResource to the new resource API recently. This might be the root cause. Could you send us reproducible sample code to debug this further? 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 : Matt [mailto:mjwat...@gmail.com] Envoyé : vendredi 29 mai 2009 00:43 À : discuss@restlet.tigris.org Objet : Re: Restlet 2.0 M3 released Hi Jerome, I think I might have found a small issue effecting the Directory class since upgrading from M2 - M3. If I view my website in Safari and reload it the served statically files (css/js/images etc) by the directory class now seem to throw 405 errors. Even if type in the full URL to the file in safari I get a 405. If I revert back to 1.2-M2 again these problems go away. Matt PS: Thanks for all your hard work. Great product. jlouvel wrote: Hi all, Restlet 2.0 M3 has just been kicked out: http://blog.noelios.com/2009/05/27/restlet-2-0-m3-released/ We hope you will like it and strongly recommend upgrading from 1.2 M2 as it provides more stability, especially on the new APIs front (resource and security) and includes fresh JARs for all supported editions (GWT, GAE and Android). Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23557 07 -- View this message in context: http://n2.nabble.com/Restlet-2.0-M3-released-tp2980083p2990789.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23566 07 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2357461 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2359003 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2360935
Re: Restlet 2.0 M3 released
Hi Jerome, The Directory class now seems fixed, and well in negotiated mode. However... the SVN version breaks negotiated mode for all the rest of my ServerResources. Unless I explicitly setNegotiated(false) for them, they all return error 406 for every GET. -Tal Jerome Louvel wrote: Hi Tal, This should now be fixed in SVN trunk. Could you confirm? 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 : Tal Liron [mailto:tal.li...@threecrickets.com] Envoyé : mercredi 3 juin 2009 08:54 À : discuss@restlet.tigris.org Objet : Re: Restlet 2.0 M3 released To add to this -- It seems that something changed with how negotiated mode is handled. It's breaking not just Directory, but also some of my other ServerResources. With my resources, I found that setNegotiated(false) fixed the problem, so I'm guessing that the bug introduced is somewhere there. Should we open an issue for this in Tigris? -Tal Matt wrote: Hi Jerome, I'll put together some sample code highlighting this issue for you. Cheers, Matt jlouvel wrote: Matt, I've just done a simple test with Directory and SVN trunk and I'm able to serve static files fine. I guess something else is causing an issue. We did migrate the Directory and its internal DirectoryResource to the new resource API recently. This might be the root cause. Could you send us reproducible sample code to debug this further? 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 : Matt [mailto:mjwat...@gmail.com] Envoyé : vendredi 29 mai 2009 00:43 À : discuss@restlet.tigris.org Objet : Re: Restlet 2.0 M3 released Hi Jerome, I think I might have found a small issue effecting the Directory class since upgrading from M2 - M3. If I view my website in Safari and reload it the served statically files (css/js/images etc) by the directory class now seem to throw 405 errors. Even if type in the full URL to the file in safari I get a 405. If I revert back to 1.2-M2 again these problems go away. Matt PS: Thanks for all your hard work. Great product. jlouvel wrote: Hi all, Restlet 2.0 M3 has just been kicked out: http://blog.noelios.com/2009/05/27/restlet-2-0-m3-released/ We hope you will like it and strongly recommend upgrading from 1.2 M2 as it provides more stability, especially on the new APIs front (resource and security) and includes fresh JARs for all supported editions (GWT, GAE and Android). Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23557 07 -- View this message in context: http://n2.nabble.com/Restlet-2.0-M3-released-tp2980083p2990789.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23566 07 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2357461 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2359003 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2360935 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2361019
RE: Restlet 2.0 M3 released
Hi there,
I'm totally new to Restlet and to REST architecture, so perhaps I still have a
fuzzy idea of what it's all about. For the moment, I'm being totally amazed by
what I've read that can be done with restlet.
Well, let's get to the point. I've downloaded the latest release (Restlet 2.0
M3) of Restlet, but now I'm getting a bit confused since I cannot be sure that
everything will work fine. I was checking the API Docs and found out that the
Post annotation, for instance, is not complete :
http://www.restlet.org/documentation/2.0/api/ . Does it prevent me from doing
POST calls to a Resource ? is it equivalent to the 'protected Representation
post(Representation entity) throws ResourceException {' method?
Sorry for this newbie question.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2360562
Re: Restlet 2.0 M3 released
To add to this -- It seems that something changed with how negotiated mode is handled. It's breaking not just Directory, but also some of my other ServerResources. With my resources, I found that setNegotiated(false) fixed the problem, so I'm guessing that the bug introduced is somewhere there. Should we open an issue for this in Tigris? -Tal Matt wrote: Hi Jerome, I'll put together some sample code highlighting this issue for you. Cheers, Matt jlouvel wrote: Matt, I've just done a simple test with Directory and SVN trunk and I'm able to serve static files fine. I guess something else is causing an issue. We did migrate the Directory and its internal DirectoryResource to the new resource API recently. This might be the root cause. Could you send us reproducible sample code to debug this further? 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 : Matt [mailto:mjwat...@gmail.com] Envoyé : vendredi 29 mai 2009 00:43 À : discuss@restlet.tigris.org Objet : Re: Restlet 2.0 M3 released Hi Jerome, I think I might have found a small issue effecting the Directory class since upgrading from M2 - M3. If I view my website in Safari and reload it the served statically files (css/js/images etc) by the directory class now seem to throw 405 errors. Even if type in the full URL to the file in safari I get a 405. If I revert back to 1.2-M2 again these problems go away. Matt PS: Thanks for all your hard work. Great product. jlouvel wrote: Hi all, Restlet 2.0 M3 has just been kicked out: http://blog.noelios.com/2009/05/27/restlet-2-0-m3-released/ We hope you will like it and strongly recommend upgrading from 1.2 M2 as it provides more stability, especially on the new APIs front (resource and security) and includes fresh JARs for all supported editions (GWT, GAE and Android). Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23557 07 -- View this message in context: http://n2.nabble.com/Restlet-2.0-M3-released-tp2980083p2990789.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23566 07 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2357461 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2359003
RE: Restlet 2.0 M3 released
Matt, I've just done a simple test with Directory and SVN trunk and I'm able to serve static files fine. I guess something else is causing an issue. We did migrate the Directory and its internal DirectoryResource to the new resource API recently. This might be the root cause. Could you send us reproducible sample code to debug this further? 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 : Matt [mailto:mjwat...@gmail.com] Envoyé : vendredi 29 mai 2009 00:43 À : discuss@restlet.tigris.org Objet : Re: Restlet 2.0 M3 released Hi Jerome, I think I might have found a small issue effecting the Directory class since upgrading from M2 - M3. If I view my website in Safari and reload it the served statically files (css/js/images etc) by the directory class now seem to throw 405 errors. Even if type in the full URL to the file in safari I get a 405. If I revert back to 1.2-M2 again these problems go away. Matt PS: Thanks for all your hard work. Great product. jlouvel wrote: Hi all, Restlet 2.0 M3 has just been kicked out: http://blog.noelios.com/2009/05/27/restlet-2-0-m3-released/ We hope you will like it and strongly recommend upgrading from 1.2 M2 as it provides more stability, especially on the new APIs front (resource and security) and includes fresh JARs for all supported editions (GWT, GAE and Android). Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23557 07 -- View this message in context: http://n2.nabble.com/Restlet-2.0-M3-released-tp2980083p2990789.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23566 07 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2357461
Re: Restlet 2.0 M3 released
Hello,
please let me add that I've also noticed this application/octet-stream
default behaviour, with a bit different implementation (both with
1.2m2 and with 2.0m3):
@Get
public Representation represent(Variant variant) throws ResourceException {
// Build and return the representation according to variant
// else return XHTML
}
I'm always getting XHTML and with logging found that the type of
variant is always application/octet-stream, even if the Accept HTTP
header states a different media type, for example application/zip
(which is the behaviour described by David F.). With Restlet 1.1.x
this worked fine, I was getting the correct representation according
to the Accept HTTP header (content negotiation).
While we're in this issue, why @Get(xml) works, while
@Get(application/zip) doesn't? IMVHO, @Get should also accept a full
media type as a parameter (even more, why not accepting one of
MediaType's constants - MediaType.APPLICATION_PDF for example - too?).
If you want to offer flexibility through simplified media types
(xml, json, jpg, pdf, zip, etc.) that's great, but make sure
the full media type specification works too.
Thanks for your efforts on making Restlet a powerful, simple and
flexible, open source REST Java framework!
On Thu, May 28, 2009 at 4:23 AM, Jerome Louvel
jerome.lou...@noelios.com wrote:
Hi David,
Sorry for the regression. I didn't expect that at this point, as many users
work from the SVN trunk or regular snapshots. We haven't had time to port
all our example code and test cases to the new resource API and have been
relying on manual testing so far.
For your issue, annotated methods all go through the converter service.
However there is a DefaultConverter in the engine that detects
Representation instances and returns them as is. But, the media type in the
annotation should definitely be taken into account, this is a bug that was
probably introduced while working on ClientResource.
We'll look at this ASAP. If you want to enter an issue report, do no
hesitate. We definitely need to have test cases covering ServerResource as
soon as possible to prevent that. One focus for 2.0 M4 is to fix pending
bugs that we have been delaying to work on features in 2.0 M3. We would
welcome help on this front as well.
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é : jeudi 28 mai 2009 06:20
À : discuss@restlet.tigris.org
Objet : Re: Restlet 2.0 M3 released
Hi Jerome-
We upgraded to the new Restlet 2.0M3 release.
A bunch of our ServerResource subclasses no longer work. (They've
worked fine since M1 and M2, and even later- it must be some recent
change that broke things) Two types of failures are involved, both
involve content negotiation. In some cases the resource is returning
the wrong variant. In other cases we get 406 -
CLIENT_ERROR_NOT_ACCEPTABLE, indicating that no acceptable variant
could be found.
I've spent a large part of the afternoon trying to debug this.
One thing to note is that these bugs won't show up when using a
typical web browser as a client, because browsers tend to send over an
Accept: */*, which means content negotiation will succeed _if there
are ANY variants at all_. But we're using javascript ajax requests,
and set the Accept header specifically to the media type we expect,
such as application/json. It is in this case, as well as any other
programatic access where Accept is set, that we now get failures.
At this point I know what's going wrong, but I'm not sure how to fix
it, nor where specifically the critical source change is which caused
the problem.
First, here is an example of the type of ServerResource that used to
work, but now does not work:
public class FooResource extends ServerResource {
�...@get(json)
public Representation getData() throws ResourceException {
return .;
}
}
Note that this is a pretty simple resource. Also not that this
resource returns Representation, and not a domain object.
What I see happening in the debugger is this:
The method doNegotiatedHandle() basically has two steps- it first gets
all available variants (via getAvailableVariants()), and then it
passes these variants to getPreferredVariant().
getAvailableVariants is returning 1 or more variants, but none of
these are deemed to be acceptable matches, therefor
getPreferredVariant() returns null, and it sends a 406 Not Accepted.
When I look at the variants returned by getAvailableVariants, I
discovered that they have the wrong MediaType. They all have the
mediatype application/octet-stream. Since this does not match the
Accept header values my clients are sending, I get the error.
Stepping through the implementation of getAvailableVariants, I can see
it loop over the available annotationInfo
RE: Restlet 2.0 M3 released
Hi David,
Sorry for the regression. I didn't expect that at this point, as many users
work from the SVN trunk or regular snapshots. We haven't had time to port
all our example code and test cases to the new resource API and have been
relying on manual testing so far.
For your issue, annotated methods all go through the converter service.
However there is a DefaultConverter in the engine that detects
Representation instances and returns them as is. But, the media type in the
annotation should definitely be taken into account, this is a bug that was
probably introduced while working on ClientResource.
We'll look at this ASAP. If you want to enter an issue report, do no
hesitate. We definitely need to have test cases covering ServerResource as
soon as possible to prevent that. One focus for 2.0 M4 is to fix pending
bugs that we have been delaying to work on features in 2.0 M3. We would
welcome help on this front as well.
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é : jeudi 28 mai 2009 06:20
À : discuss@restlet.tigris.org
Objet : Re: Restlet 2.0 M3 released
Hi Jerome-
We upgraded to the new Restlet 2.0M3 release.
A bunch of our ServerResource subclasses no longer work. (They've
worked fine since M1 and M2, and even later- it must be some recent
change that broke things) Two types of failures are involved, both
involve content negotiation. In some cases the resource is returning
the wrong variant. In other cases we get 406 -
CLIENT_ERROR_NOT_ACCEPTABLE, indicating that no acceptable variant
could be found.
I've spent a large part of the afternoon trying to debug this.
One thing to note is that these bugs won't show up when using a
typical web browser as a client, because browsers tend to send over an
Accept: */*, which means content negotiation will succeed _if there
are ANY variants at all_. But we're using javascript ajax requests,
and set the Accept header specifically to the media type we expect,
such as application/json. It is in this case, as well as any other
programatic access where Accept is set, that we now get failures.
At this point I know what's going wrong, but I'm not sure how to fix
it, nor where specifically the critical source change is which caused
the problem.
First, here is an example of the type of ServerResource that used to
work, but now does not work:
public class FooResource extends ServerResource {
@Get(json)
public Representation getData() throws ResourceException {
return .;
}
}
Note that this is a pretty simple resource. Also not that this
resource returns Representation, and not a domain object.
What I see happening in the debugger is this:
The method doNegotiatedHandle() basically has two steps- it first gets
all available variants (via getAvailableVariants()), and then it
passes these variants to getPreferredVariant().
getAvailableVariants is returning 1 or more variants, but none of
these are deemed to be acceptable matches, therefor
getPreferredVariant() returns null, and it sends a 406 Not Accepted.
When I look at the variants returned by getAvailableVariants, I
discovered that they have the wrong MediaType. They all have the
mediatype application/octet-stream. Since this does not match the
Accept header values my clients are sending, I get the error.
Stepping through the implementation of getAvailableVariants, I can see
it loop over the available annotationInfo objects (one for each
annotated method), and it find the _correct_ mediatype in the
annotation. It then passes a combination of the java method return
type as well as a new Variant created with the correct mediatype to
the ConverterService.
**Here is the problem***
The converter service is _ignoring_ the correct Mediatype (as passed
in within a Variant instance), and is only using the
java-method-return-type to look up possible variants that it's
registered converters can produce. Our methods have a return type of
Representation. Somewhere there is code that is deciding that
Respresentation class maps to application/octet-stream.
Questions:
- Why is the converter service being used at all here? (we have NOT
registered ANY converters, and are handling the creation of our own
Representations.)
- Why is the mediatype specified in the annotation being ignored?
What's the point of having it declared in the annotation at all if the
strategy is to just ask the converter service for what it can produce
instead?
- Does the Restlet team have any test code that they maintain that
could be used to avoid regressions like this? It's a little
frustrating- we're really writing _very_ simple Resources, and we're
following the format of the simplest of example code directly from the
Restlet docs.
Is anyone else having similar issues?
-Dave Fogel
Re: Restlet 2.0 M3 released
Hi Jerome, I think I might have found a small issue effecting the Directory class since upgrading from M2 - M3. If I view my website in Safari and reload it the served statically files (css/js/images etc) by the directory class now seem to throw 405 errors. Even if type in the full URL to the file in safari I get a 405. If I revert back to 1.2-M2 again these problems go away. Matt PS: Thanks for all your hard work. Great product. jlouvel wrote: Hi all, Restlet 2.0 M3 has just been kicked out: http://blog.noelios.com/2009/05/27/restlet-2-0-m3-released/ We hope you will like it and strongly recommend upgrading from 1.2 M2 as it provides more stability, especially on the new APIs front (resource and security) and includes fresh JARs for all supported editions (GWT, GAE and Android). Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2355707 -- View this message in context: http://n2.nabble.com/Restlet-2.0-M3-released-tp2980083p2990789.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2356607
