On 3/30/12 5:25 AM, Sergey Beryozkin wrote:
>> Another option is to extend the ClientResponse from the Response. This
>> makes the Response.Status/StatusType reuse more natural, but client
>> side suffers from the "weird method" issues that we identified in the
>> common Request/Response model. IOW, one of the main issues why we
>> started this exercise has not gone away... Also, reusing WAE as a
>> common exception super-type is problematic due to the need to downcast
>> the Response in the WAE on the client side or do some other similar
>> tricks.
>
> I thought the issue was that some of the current Response methods
> introduced in 2.0 did not quite make sense on the server side ?
> Response in 1.1 has 3 methods, getStatus(), getEntity() & getMetadata(),
> all of these methods have the complete sense on both ends, they are just
> not client-friendly.
>
When you think about it, even with the current API "getMetadata()"
doesn't fit either and would never be used.
For a ClientResponse extends Response: I agree that all three methods
sort-of work.
>>
>> The last option is to keep the common Response mostly as is and
>> rollback only the changes in the Request. The advantage is that reuse
>> of the member types is natural on both, client and server. The
>> disadvantage is that the "weird method" syndrome is visible again on
>> both, client and server. The good thing would be that with new
>> filtering infrastructure not based on the Request/Response types, the
>> problem would mainly be visible in some client scenarios. Also reusing
>> WAE as the common super-type becomes more possible s well as
>> ResponseBuilder.
>>
>> I wish Status& StatusType were not defined inside the core.Response.
>> Things would have been much more simpler. All in all, seems to me we
>> should either do a complete radical cut between the client and the
>> server or keep the common Response. To me the middle option is just
>> not appealing enough. It looks more like a collection of the problems
>> from both worlds rather than a good solution.
>>
>> Thoughts?
>
> I like the following options:
> - ClientResponse is standalone and optimized for the client to retrieve
> the data and headers. However in this case we should not be too
> concerned about WAE or Response (via WAE) 'leaked' to the client runtime
> because as I said above there was nothing in Response signature that the
> client were not capable of working with. We can think about (internal)
> conversions/adaptation between Response & ClientResponse if the 'leak'
> is not desired but I'd not worry about it a lot.
>
> - ClientResponse extending Response
>
> This is may not look like the good design decision but it makes a
> complete sense in terms of "ClientResponse is Response *optimized* for
> the client to process the server response". That will also make the idea
> of reusing child server exceptions with the root WAE practical.
>
I agree with Sergey. ResponseBuilder can also be re-used when you want
to abort in a client-side filter (i.e. the cache example).
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com