[jax-rs-spec users] [jsr339-experts] Re: Re: Consistency and awkwardness issues with Request/Response/Filter API

From: Sergey Beryozkin <>
Date: Wed, 21 Mar 2012 21:24:03 +0000

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