Hi Todd,

Thanks for your feedback.  Fault handler of Restlet component should
be consistent with other components.  It sounds like it isn't.   Let
me look into it.

Cheers,
William

On Mon, Feb 23, 2009 at 7:21 PM, tfredrich <[email protected]> wrote:
>
> I'm utilizing the Restlet component (via a Trunk build) and am interested in
> better understanding error handling behavior via the exchange fault message.
> BTW, I appreciate your work on this component!  Good stuff, indeed.
>
> In essence, I'm simply using camel-restlet to expose a JSON RESTful service
> with CRUD behavior.  The route looks something like this:
>
> from("restlet:http://localhost:8080/people/person/{userId}?restletMethod=GET";)
>    .intercept(new AuthenticationInterceptor())
>    .process(new QueryStringProcessor())
>    .process(new GetPersonProcessor())
>    .marshal(format)
>    .process(new JsonpProcessor());
>
> Of interest for my question is the GetPersonProcessor, which is responsible
> for retrieving the person object from a storage repository.  When a
> non-existent userId is requested, the GetPersonProcessor does not return a
> person object and, instead sets the restlet response header to 404 (not
> found).  After reading the Camel manual, I thought it best to set the 404
> along with a fault message on the exchange, but the restlet component
> doesn't appear to acknowledge the fault and composes its response from the
> out message.  So, unless I misunderstand, I have to set the 404 on the out
> message header (for the restlet component) and set the body on the fault
> message (for camel to terminate the pipeline).
>
> Now for the question:  Is this the way I should be doing things?  Or
> could/should the DefaultRestletBinding utilize the fault message to compose
> its response, if a fault message exists?  Your feedback is much appreciated.
>
> Thanks,
> --Todd
> --
> View this message in context: 
> http://www.nabble.com/Restlet-Component-Fault-Handling-tp22173327p22173327.html
> Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
>
>

Reply via email to