users@jax-rs-spec.java.net

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

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Thu, 22 Mar 2012 15:49:08 +0000

On 22/03/12 15:40, Marek Potociar wrote:
>
> 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.
>

of course it does. You are talking about the same package. However I
read you saying "We should perhaps also think about whether client-side
components should *not* go into a separate package"...while I see a
.client sub-package being already available.

Perhaps you were talking about it in the context of this thread where
the classes shared between client and server are discussed, if so then I
did misread your comment

Cheers, Sergey

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


-- 
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com