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