Re: [docs] Poll for participation and input.

Some of my TOC additions embedded, feel free to comment... (incorporated the suggestions from issue 21 and those made in this thread already) I also added a big section on doing reslet based development as I think there is a big difference in listing 'what it is and does' versus 'how one

StackOverflow on Restlet Exception

Quick question using Restlet 1.0.5, Java 1.5, Tomcat 5.5.28 and the Spring Restlet Extensions: On any exception inside of a restlet handle() method, we are receiving a stack overflow due how Restlet's is handling the exception. We understand what the exception is (Connection pooling issue in the

RE: StackOverflow on Restlet Exception

One more observation, If I add an already-done? check to ApplicationHelper.java in the start() method, these seems to alleviate the symptoms, by preventing the N number of Tunnel, Status, and Log filters from getting added to the same application object on every Restlet call. +cs

Re: StackOverflow on Restlet Exception

Hi Christopher, Thanks for reporting this issue and for pointing to a solution. We already have a related bug report here: http://restlet.tigris.org/issues/show_bug.cgi?id=367 We'll fix this ASAP and release 1.0.6 during the week. Best regards, Jerome 2007/10/8, Christopher Sun [EMAIL

Re: HEAD not well supported?

Jerome Louvel contact at noelios.com writes: Hi all, I'm a bit late in the discussion it seems :) Let me try to explain how the support for HEAD was designed in Restlet. Following the definition of HEAD from the HTTP spec [1], I got convinced that HEAD was only a special GET and

Re: [docs] Poll for participation and input.

Marc Portier mpo at outerthought.org writes: Some of my TOC additions embedded, feel free to comment... (incorporated the suggestions from issue 21 and those made in this thread already) I also added a big section on doing reslet based development as I think there is a big difference

Re: Thread-safety in Guard

Funny you should ask! I can highly recommend Java Concurrency in Practice by Brian Goetz, Josh Bloch, Joe Bowbeer, David Holmes, Doug Lea, and me (Tim Peierls). My recommendation is probably biased by the fact that I helped write it, but we've had a lot of good feedback. --tim It is a great

RE: StackOverflow on Restlet Exception

Christopher, The issue is now fixed in SVN trunk and 1.0 branch. Best regards, Jerome -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Jerome Louvel Envoyé : lundi 8 octobre 2007 16:54 À : discuss@restlet.tigris.org Objet : Re: StackOverflow

RE: RE: StackOverflow on Restlet Exception

Thanks Jerome for the fast turn-around. +cs -Original Message- From: Jerome Louvel [mailto:[EMAIL PROTECTED] Sent: Monday, October 08, 2007 1:18 PM To: discuss@restlet.tigris.org Subject: RE: StackOverflow on Restlet Exception Christopher, The issue is now fixed in SVN trunk and 1.0

Index files don't work with Directory and clap://

... but I'd like them to. I assume the trouble is that you can't really get listings from the classpath, so the content negotiation behavior is broken. Do you think there is a way I could add workarounds to the existing Directory/DirectoryResource implementation, or do I just need a custom

Slow to retrieve Request Entity?

I seem to be having some kind of performance problem trying to retrieve the request entity. I've tried a few different approaches, and I can't figure it out. I'm using Restlet 1.0.5 with the bundled Simple server, Intel Core Duo, Mac OS X 10.4.10, Java 5.0, Eclipse. I've tried reducing my test

problems using gzip encoding

I am trying use gzip for all my representations and use the tunnel filter, on the application, to automatically decode the body before passing it to the router. This how i encode the rep new EncodeRepresentation(Encoding.GZIP, new StringRepresentation(getXStream().toXML(records),