RE: Guidance on Atom/APP in Restlet

Hi Tim, Using an object serialization representation does reintroduce strong coupling between a REST client and server. It should only be done for optimization purpose, as an alternative to more reusable and interoperable JSON / XML representations. But wait! XML and JSON do introduce

RE: Re: REST in mobiles

Hi Abdul, J2ME has such a limited set of APIs that I highly doubt that Jersey would work there (you should ask them though). Android is a full featured Java-based OS for mobile (http://www.android.com/). Doesn't it work for you? Best regards, Jerome Louvel -- Restlet ~ Founder and Lead

RE: GAE + GWT + Restlet 2.0 M3 + challenge response is null on server side

Hi Lauri, Thanks for sharing this workaround. The current code sets the user and password given in ChallengeResponse on the internal RequestBuilder that is used: http://google-web-toolkit.googlecode.com/svn/javadoc/1.6/com/google/gwt/http

RE: Problem configuring spring ext in 2.0M3

Hi Ryan, I have added support for ServerResource in the Spring extension after 2.0 M3. If you try with a recent 2.0 snapshot (unstable), you should get it working. If not, enter an issue as suggested by Rhett. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~

RE: FileClientHelper

Hi Rémi, It seems to me that Directory should indeed ignore your file because “001” and “bak” are unknown extensions. Could you enter an issue in the tracker? Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios

RE: Help! -- Error handler isn't working

Hi Schley, I could open your link (404). By default, the exception doesn't appear in the browser to not expose too much internal details. You can customize the StatusService if needed. I agree it would be nice to have such an option available so I've updated this RFE: Return clear status

RE: Resolve to Resources inside another Resource

Hi Raymi, Sorry, but I'm not sure I understood your question. On the server-side, you could GET the resource at http:///user/21; by doing this: getContext().getClientDispatcher().get(http:///user/21;) I hope this will help. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead

RE: Premature EOF / Broken Pipe

Hi Timothy, Let us know how it goes when using Jetty for example as the HTTP server connector. If you were using Tomcat, you might want to check this issue which might be related: “getText() returns empty text with Tomcat” http://restlet.tigris.org/issues/show_bug.cgi?id=843 Best

RE: Parameters of media-type

Hi Evgeny, Thanks for reporting this issue. It should be fixed in SVN trunk. I have also trimmed spaces around parameter names when accessing them via MediaType#getParameters(). Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~

Re: Help! -- Error handler isn't working

I changed the package name last night :( http://vangaea.svn.sourceforge.net/viewvc/vangaea/trunk/src/main/java/com/hyper9/vangaea/server/rest/BaseResource.java?view=markup Here is the updated link. Thanks! -- -a Only two things are infinite, the universe and human stupidity, and I'm not

Re: Guidance on Atom/APP in Restlet

All valid points. There must be cooperation between a client and server at some level! I have two problems with RPC style implementations on the Web: 1) The RPC paradigm hides the advanced properties of the Web and makes them really difficult to leverage 2) The RPC protocol and serialization

Empty @Get() annotation overwrites already retrieved representation mimetype

Greetings, The following code at ServerResource#doHandle(AnnotationInfo ,Variant ) seems backwards perhaps. (2.0m3snapshot) if (resultObject != null) { // TODO This is a shortcut in case the resource does not // precise the media-type of the