On Wed, Jul 11, 2012 at 8:04 PM, Richard Berger <rich...@landisfamily.org>wrote:
> Do you think that this problem has persisted this long due to the lack of > clients built with Restlet (vs. the much larger number of servers built > with Restlet)? > That's not really a fair question: You're leading the witness, counsel. :-) The concept of tunneling exception information via the Status is meaningless unless both client and server are Restlet-based, and one of the wonderful things about Restlet is that it doesn't impose that kind of coupling on the developer. Clients can't in general assume a particular structure of the error response entity; all they can really count on is the status code and associated reason phrase. If the client has specific knowledge of how a given server serves its error responses, Restlet has all the tools necessary to take advantage of that knowledge. Still, since the client proxying machinery can do such a neat job of creating the illusion of a remote Java call in the case that you *do* have Restlet on both sides, it seems a shame that the illusion doesn't extend quite as neatly to exceptions. There might be an issue already to address this; I can't find it just at the moment. Thanks again for providing the workaround!! > You're welcome! --tim ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2984237
