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.
Marek
>
> Hope it makes some sense
>
> Sergey
>
> On 21/03/12 22:01, Marek Potociar wrote:
>>
>> On Mar 21, 2012, at 10:24 PM, Sergey Beryozkin wrote:
>>
>>>
>>>>> We should perhaps also think about whether client-side components
>>>>> should not go into a separate package so that it is easier to split
>>>>> the client and server api into separate jars in the future.
>>>>>
>>>>
>>>> +1
>>>
>>> How does having client-side components going into a separate package prevents splitting the api into separate jars ?
>>
>> Perhaps you have misread my comment - it doesn't prevent it, it makes it more possible.
>>
>> Marek
>>
>>>
>>> Thanks, Sergey
>>>
>>>
>>>
>>>>
>>>>>> All and all, my proposal probably needs some polishing, but the idea
>>>>>> is to have specific contracts at each interception point. I think
>>>>>> this is important because we can control exactly what a user can (and
>>>>>> more importantly) *cannot* do. With the current API, IMO, there's
>>>>>> just way too many weird edge cases you have to code for.
>>>>>
>>>>> I think the main disadvantage of the current API is that it is not
>>>>> mutable, (which is impossible to achieve by extending JAX-RS 1.x
>>>>> Request/Response in a sane way...). Another, but solvable,
>>>>> disadvantage is that it is not possible to clearly scope filters to a
>>>>> particular side.
>>>>>
>>>>
>>>> The scoping is solvable with the current API with a scoping annotation
>>>> (to be scanning friendly). But...if you require the annotation, this is
>>>> no different, IMO, than having client/server specific interfaces. If you
>>>> don't require it, you run the danger of users forgetting to apply the
>>>> annotation and problems surfacing at runtime.
>>>>
>>>> Also:
>>>>
>>>> A 3rd disadvantage of the current API is that some methods have
>>>> different behavior in different contexts.
>>>>
>>>
>>>
>>> --
>>> Sergey Beryozkin
>>>
>>> Talend Community Coders
>>> http://coders.talend.com/
>>>
>>> Blog: http://sberyozkin.blogspot.com
>>