jsr339-experts@jax-rs-spec.java.net

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

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Thu, 22 Mar 2012 16:40:11 +0100

On Mar 21, 2012, at 11:07 PM, Sergey Beryozkin wrote:

> 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.
>
> Perhaps I did. How about dropping one more sentence or two and explaining what is not ideal with the current package layout as far as the possible split is concerned ?

Having multiple jars with a classes in the same package is discouraged by Java SE. Also, if I'm correct, with the Jigsaw implemented in Java SE 8 it will be completely forbidden. So if we ever want to split the API into multiple jars (e.g. client / server), we should try to make sure that the client/server specific components do not mix up in the same packages now.

Makes sense?

Marek

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