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 ?
Sergey