On 3/30/12 11:36 AM, Marek Potociar wrote:
> Additionally, we need to find a way how to construct the ClientResponse in the client request filter in case we want to abort the filter chain. So, what are the options?
>
Use ResponseBuilder. There's really nothing client specific in building
a response, is there?
> - create a specific ClientResponseBuilder
> - construct and initialize a client filter response context somehow and set it on the request context (I tried that, feels weird when using it).
> - build a core.Response and document that it will be automagically converted to the ClientResponse somehow by the JAX-RS runtime.
>
> And when it comes to reusing WebApplicationException on the client side, what do we do?
>
> - force users to downcast wae.getResponse() to ClientResponse?
> - introduce a special ClientResponse static method to convert a Response into ClientResponse and force users to use that?
Yup. Ugly solution, but the simplest.
> - tell the client API users to use the server API Response whenever they need to process WAE on the client side (and somehow define the meaning of Response.getEntity() and getMetadata() for this particular case)?
>
> None of the options above looks appealing IMO.
>
> Actually, seems to me that the best alternative for the new filtering API as well as for a unified exception hierarchy, the one that minimizes the number of issues we have to solve, is to keep a common, extended core.Response for both sides and deal with the differences in the Response methods javadoc. This is the alternative that users will find most natural to use IMO. Assuming that the response on the server side is typically just built and returned, the server-side users will hardly ever have to deal with the nuances behind the readEntity(...) methods (protecting these users by an artificial extending ClientResponse from Response is just not worth the effort and confusion). And for the client side users, the common Response is no worse than a ClientResponse extended from the Response. In fact it's easier to accept and less confusing than a "ClientResponse extends Response" solution ("gee, why does a client response extend the server response? does it mean I can also us!
e it to re
turn one from the server? yes? no? hmm...").
>
A shared Response might work. Do you have an iteration we can look at?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com