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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com