users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Concerns about the client-side exception hierarchy

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Fri, 30 Mar 2012 17:36:22 +0200

On Mar 30, 2012, at 12:18 PM, Bill Burke wrote:

>
>
> On 3/30/12 5:31 AM, Sergey Beryozkin wrote:
>> Hi Bill
>> On 29/03/12 16:26, Bill Burke wrote:
>>> You could punt on server-side exceptions and just have a client
>>> hierarchy. (If we went the ClientResponse route).
>>>
>> I guess it would be the only option in this case as far as the
>> introduction of child (server) exceptions is concerned, I'm however
>> becoming 'fond' of your original idea of the app developer being able to
>> 'throw new BadClientRequestException()'. I think if we can not reuse
>> such exception then at this stage we should punt on all the child
>> exceptions and simply refactor a bit the current client-side hierarchy
>> as was suggested originally and review the idea in post 2.0
>>
>
> Ya, I'm fond of it too. It works really nice in practice. I just know we'll have some lame 'Spring-JAXRS" project that will do just this...
>
> BTW, I still think ClientResponse extending Response would solve the problem.

I wonder what exactly does "ClientResponse extends Response" solve?

The extended response still contains methods like

- Object getEntity()
- MultivaluedMap<String, Object> getMetadata()

and we need to deal with them in the javadoc somehow at least.

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?

- 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?
- 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 use it to return one from the server? yes? no? hmm...").

Marek

> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com