RE: Newbie web app architecture question

Hi William, [...] That makes perfect sense, and the example code was helpful. Setting the status code in a case statement in the resource constructor leaves me feeling like there's an opportunity for an additional abstraction, but it's perfectly workable for now, and I'll let you

RE: Shell extension for Restlet

Hi Davide, 1) Some complimentary features that would be great to add are : - start/stop listeners in any protocol (mainly HTTP/HTTPS for now) - receive incoming calls (to simulate a server-side application from a browser) can you better explain these features? Yes, I would like

RE: Aborting request in Filter

Hi Paul, I agree and changed the behavior in SVN trunk. Also, I'm now logging a warning if such an error is detected at runtime. Best regards, Jerome -Message d'origine- De : Paul J. Lucas [mailto:[EMAIL PROTECTED] Envoyé : jeudi 10 janvier 2008 21:40 À :

Re: Restlet 1.1 M1 Spring Extension issue

Did you modify the test case at all? I noticed the snippet you posted has the @Test annotation whereas the code in SVN trunk does not have that annotation. The test in the trunk runs fine. On Jan 13, 2008 1:36 AM, dev dev [EMAIL PROTECTED] wrote: Without looking at the Restlet code, i'm having

RE: Aborting request in Filter

Hi all, I have checked in SVN the changes to Filter. I finally used an int instead of an enum to prevent the apparition of a new artifact in the Javadocs, increasing the perception of complexity for users (this is subjective I know). Here are the details of the change: Filter.beforeHandle()

New mailing list for code contributors

Hi all, In order to keep up with the increased number code contributions and project extensions (JAX-RS, Shell, JiBX, JAXB, etc.), I have created a new mailing list dedicated to technical exchanges such as code style, patch-related discussions, IDE set-up, build process, etc. The list address

Re: Aborting request in Filter

Sorry for not commenting earlier, but Anyway, in thinking about this more, I don't think a filter should have any knowledge of its next filter. When a request is received, the engine should have a list of filters, i.e., the list itself should be external to all the filters. So,

PUT with no entity (architecture question)

Hi, I'm designing implementing my first REST-style API. It's for an existing application. I'm using Restlet 1.1-M1 and have found it very cleanly designed and easy to use. I've run into a problem where I can't seem to implement one of the resources in the way that makes most sense to

Re: PUT with no entity (architecture question)

I can't fault your design given your constraints. I think the general concept: identifying links with hierarchical URIs descending from the URI of each linked object, is at least a common idiom if not an established pattern. I have both seen and used this style a number of times. I have also