jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Re: Re: Consistency and awkwardness issues with Request/Response/Filter API

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Tue, 27 Mar 2012 18:42:51 +0200

On Mar 22, 2012, at 11:05 PM, Sergey Beryozkin wrote:

> On 22/03/12 20:48, Bill Burke wrote:
>>
>>
>> On 3/22/12 12:04 PM, Sergey Beryozkin wrote:
>>> On 22/03/12 15:45, Marek Potociar wrote:
>>>>
>>>> On Mar 21, 2012, at 11:24 PM, Sergey Beryozkin wrote:
>>>>
>>>>> One advantage of having Response used on the client and server sides
>>>>> is that it allows us to consider reusing WAE on both the client and
>>>>> server sides.
>>>>> Having ClientResponse& Response (or similar) makes this more awkward.
>>>>
>>>> Would introducing a Message interface inherited by Request, Response,
>>>> ClientResponse solve the issue? This interface could be then accepted
>>>> by the WAE constructor. Not sure what should it contain though other
>>>> than headers getter (perhaps intercepted entity input stream getter?).
>>>>
>>>>> Would it make sense to consider creating ClientResponse which extends
>>>>> Response ? That would probably be a good compromise. Response can
>>>>> still be used on both ends, and cast to ClientResponse on the client
>>>>> side if needed
>>>>
>>>> That's ugly IMHO.
>>>>
>>>
>>> You just keep issuing your one-phrase responses without providing the
>>> justification of what exactly do you mean. Is my proposal not good ? OK,
>>> just say something meaningful as opposed to trying to discourage any
>>> further conversation.
>>>
>>> By the way, I do not like your proposal, because WebApplicationException
>>> will become a sink of whatever cares to implements Message and will make
>>> the 'life' of custom WebApplicationException mappers more difficult.
>>>
>>> WebApplicationException is not supposed to represent the client side
>>> errors as we discussed at length, I have to get to doing my item and
>>> providing the patch asap
>>>
>>
>> Throwing WAE from a Reader or Writer with a Response in it on the client
>> side, just doesn't make sense to me anyways. In the
>> MessageBodyReader/Writers I've written, I try to avoid using WAE
>> altogether because of this.
>>
> The MBR or MBW may not necessarily know whether it's executed on the client or the server side. But besides WAE does not have to be initialized from Response, the important bit it can return the Response representing the state (status, headers if any, the entity if any).
>
> I thought a bit more about the relationship between ClientResponse & Response. IMHO, Response does adequately represent the state of the server response but it's not optimized for the client processing it.
>
> I think that Response should still be optionally visible to the client runtime, via WAE.getResponse() at least. Having response.getStatus() may be all the client needs and thus be sufficient.
>
> Having WAE shared between the client & server is also important for the current idea to do with introducing the finer-grained exceptions to work well - the server should be able to throw ClientBadRequestException and the WAE mapper should be able to catch it. Likewise on the client side the WAE catch block should be able to catch it with the runtime guaranteeing that ClientBadRequestException.getResponse().getStatus() == 400.
>
> But what about the client-specific processing of Response. Marek is not impressed with the idea of ClientResponse extending Respone.
>
> What about supporting the adaption of Response to ClientResponse ?
>
> public abstract class ClientResponse {
> public static ClientResponse fromServerResponse(Response);
> }
>
> or similar. Thus the WAE processor can easily migrate to ClientResponse if desired
>
> Comments ?

I guess I still don't get the use case for the client-side "WAE processor". My understanding was that on the server side any exception should be caught and mapped into a response, but on the client side it is exactly opposite - in case of a typed response retrieval (e.g. get(String.class)) a non 2xx response will be transformed by the JAX-RS runtime into a proper exception and thrown to the application layer. So where does this client-side "WAE processor" come to the picture?

FWIW, because of the above I'm not convinced JAX-RS runtime should be throwing WAE on the client side. WAEs thrown by MBR/MBW on the client should be automatically transformed into proper client-side response objects or exceptions (depending on the response retrieval method).

The above also means that WAE is perhaps not the right unified exception root type. Perhaps we can create the common root exception by extracting some sub-interface from WAE (and have WAE extend this new root exception)?

Marek

>
> Sergey
>