RE: stumped - NPE in ClapClientHelper
Hi Rob, I've added some code to prevent the NPE, log a warning and return a 304 status in this case. Changes in SVN trunk. Best regards, Jerome -Message d'origine- De : Rob Heittman [mailto:[EMAIL PROTECTED] Envoyé : jeudi 27 mars 2008 03:19 À : discuss@restlet.tigris.org Objet : Re: stumped - NPE in ClapClientHelper Answer: clap://thread doesn't return a useful classloader under procrun. Workaround: use clap://system instead. Probably this needs a better failure mode than an NPE, but I'm not remotely sure what =) On Wed, Mar 26, 2008 at 4:44 PM, Rob Heittman [EMAIL PROTECTED] wrote: With Restlet 1.1M2, when running as a *service* under Windows (using procrun) I get an NPE in ClapClientHelper line 125, which I think is/was:
RE: Unit test (with httpunit)
Hi Daniele, I have some HttpUnit tests around a Servlet. Now I am creating some mock services that uses the ServerServlet as servlet. Well, with such a serevlet mapped at, say, mock, httpUnit cannot find anyone answering it's request. BTW, If at mock answer a standard servlet, everything works. When you test your application with a browser or a regular client, does your mock Restlet application work? Anyone aware of this problems? Any workaround? Any other idea to unit test a Restlet integrated in a servlet environment? From my point of view, there is no reason why HttpUnit wouldn't work with ServerServlet like with any other Servlet. Ah, if I run application in a jett container, everything works perfectly so is just a HttpUnit issue here... Do you mean if you run your Restlet application in standalone mode with a Jetty connector (because Jetty also has its own Servlet container)? Best regards, Jerome
Re: Another newbie question: when is it appropriate to use GET parameters?
On Sun, Mar 23, 2008 at 7:56 PM, Ian Clarke [EMAIL PROTECTED] wrote: When is it appropriate to use a query string to pass parameters to a REST API call? For example, why is: http://blah/user/1234 better than: http://blah/user?id=1234 ? It depends on what you're doing. One of the biggest reasons to use the pure version is that that is fully cachable. I.e., using GET parameters triggers often non-obvious caches and crawlers -- the simplest being that many of them won't cache URLs with parameters. Have fun, John
Re: Series.getValues()
ListParameter doesn't seem like the right abstraction, even when provided as Series. Parameters seem more akin to a multimap than to a sequence of key-value pairs. And for the (many?) users who don't take advantage of the multiplicity they are closer to regular maps. If sequence of keys is important, one could use a LinkedHashMap. But maybe this would be too much upheaval to contemplate. --tim On Tue, Mar 25, 2008 at 6:08 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Paul, You can use ListParameter if you write more generic utility classes: [...] The bonuses are: 1. The Series class doesn't leak into places that shouldn't have a dependency on it since you're using an ordinary List. 2. The solution above is completely generic and can be used for lots of other stuff. If you want, you can add other Util methods that are convenience methods to lessen typing. You filter approach is nice and very flexible. However, if you call the subList() method, I don't see how the Series class leaks, you can do this: ListParameter fooParams = in.sublist(foo); You still have the Restlet Parameter class dependency so you might still prefer the new getValuesArray(foo) method anyway. Best regards, Jerome
Re: Another newbie question: when is it appropriate to use GET parameters?
On Thu, Mar 27, 2008 at 11:33 AM, Aron Roberts [EMAIL PROTECTED] wrote: On Thu, March 27, 2008 11:07, John D. Mitchell wrote: [...] One of the biggest reasons to use the pure version is that that is fully cachable. This is to put in another strong recommendation for the recent book by Leonard Rosenthal and Sam Ruby, RESTful Web Services, which you can purchase via the Books link on the Restlet website: http://www.restlet.org/documentation/books This book provides deeply thought out suggestions for 'normative' practices in building RESTful services, and covers the topic of when to use pure resource identifiers and when to use query parameters. Indeed! Good point. Thanks, John
RE: Re: StreamClientCall and FH exhaustion
I'll give it a shot. It may be a bit, we've solved the problem by moving the Apache's HTTPClient. I'll also create an alternate test. The one I wrote uses our internal services; obviously not a good candidate for a standalone test. Thanks for looking into this From: Kevin Conaway [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2008 2:23 PM To: discuss@restlet.tigris.org Subject: Re: StreamClientCall and FH exhaustion Thanks Jerome. Matt, could you see if that solves your problem as well? If possible, can you attach your test case to 439? On Tue, Mar 25, 2008 at 5:20 PM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Kevin, Very nice work (as always). The patch is in SVN trunk with some slight improvements (more getContentLength() refactoring). Added complete() handling on SimpleCall as well. Best regards, Jerome -Message d'origine- De : Kevin Conaway [mailto:[EMAIL PROTECTED] Envoyé : mardi 25 mars 2008 21:18 À : discuss@restlet.tigris.org Objet : Re: StreamClientCall and FH exhaustion Yes. If the response is chunked, the stream won't get closed. In general, its not a great idea to close a socket *stream with the intention of closing the socket. I'm going to attach a patch to 439 with the following fixes: 1.) In StreamClientCall, the response entity representation is now wrapped with a WrapperRepresentation that will close the associated socket when release() is called 2.) In HttpServerCall, a new method called complete() was added that is called after commit(). StreamServerCall implements this by: A.) Flushing the response output stream B.) Exhausting the request input stream C.) Closing the request socket We exhaust the request input stream in case the client is still writing a request entity to the socket. If we close the socket without reading the entire request, the client would get IOExceptions while it is still writing 3.) I also modified StreamServerHelper.getRequestEntityStream() and StreamClientCall.getResponseEntityStream() to always return a KeepAliveInputStream. The raw stream should never be exposed to callers as they can (and most likely will) close it at will. Closing the input/output stream of a socket closes the entire socket so it should be protected as much as possible. Kevin On Tue, Mar 25, 2008 at 4:08 PM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Kevin, The InputRepresentation.release() method currently closes the underlying stream. As we currently don't support persistent connections, the closing of the input stream should actually close the socket input stream and as a consequence the socket. Do you obtain results that suggest it isn't happening like this? Best regards, Jerome -Message d'origine- De : Kevin Conaway [mailto:[EMAIL PROTECTED] Envoyé : lundi 24 mars 2008 18:47 À : discuss@restlet.tigris.org Objet : Re: StreamClientCall and FH exhaustion Assuming the response entity is NOT pre-fetched, what about wrapping the InputRepresentation used to store the response so that release() closes the associated client socket. Is it safe to assume that the socket is no longer needed once a user calls release() on the Response entity? On 3/23/08, Kevin Conaway [EMAIL PROTECTED] wrote: Jerome, I think you misunderstood me. I was suggesting it might be useful to allow the client to tell Restlet to read and store the response entity to be consumed later. If the response entity is read right away and stored, there would be no need to keep the connection open and the entire request/response cycle could be completed in short order. On Sun, Mar 23, 2008 at 2:28 PM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Kevin, Why not, but what would be the use case for making such a request? If a client application isn't interested in the entity, it can always issue a HEAD request. Best regards, Jerome -Message d'origine- De : Kevin Conaway [mailto:[EMAIL PROTECTED] Envoyé : samedi 22 mars 2008 13:33 À : discuss@restlet.tigris.org Objet : Re: StreamClientCall and FH exhaustion Would it make sense to add an option to the Client or Request that specifies whether Restlet should prefetch the Response entity? If the response entity was prefetched, the
