Actually, I'm wondering is a good idea at all,
On 23/01/13 15:52, Sergey Beryozkin wrote:
> On 23/01/13 15:38, Santiago Pericas-Geertsen wrote:
>> Hello Experts,
>>
>> We recently had a discussion with Pete Muir related to name binding in
>> JAX-RS and CDI (interceptor binding). As a result, I propose making a
>> small change to our spec in order to align our semantics with CDI's.
>>
>> The proposed change relates to the use of multiple binding
>> annotations. There are two sub-cases: (i) multiple binding annotations
>> on a resource method or class and (ii) multiple binding annotations on
>> the filter or interceptor.
>>
>> (i)
>>
>> @A class MyFilter1 ...
>> @B class MyFilter2 ...
>>
>> // Binds both MyFilter1 and MyFilter2
>> @A @B public Foo myMethod1() ...
>>
>> (ii)
>>
>> @A @B class MyFilter ...
>>
>> // Binds MyFilter
>> @A @B public Foo myMethod2() ...
>>
>> There are no changes w.r.t. (i), our semantics agreed with CDI's.
>> Before this change, we could bind MyFilter to myMethod2() using either
>> '_at_A or @B'. In order to align with CDI, we will now require both '_at_A
>> and @B' as shown above.
>
> So effectively specific method name bindings should contain all ones of
> the given filter for it to be applicable ?
First, I was not correct above, this update would assume that the name
bindings of a specific filter would have to contain all the bindings of
a specific method for this filter be bind-able to this filter.
This may make sense in CDI but CDI is at different level than JAX-RS,
for example, replacing @A & @B with something more meaningful:
@GZIP @LOG public Foo myMethod1()
@LOG public Foo myMethod1()
Having a user to make sure a filter can log & gzip in order to process
myMethod1 does not make sense IMHO, possible to implement by sharing
some base code, etc, but just does not make sense from JAX-RS point of view.
Thus I'm -1 (unless of course I've misread the proposal - quite possible
:-)).
Thanks, Sergey
>
> What else is affected ?
>
> Thanks, Sergey
>
>>
>> Overall, this is a rather minor change given that (i) is much more
>> common than (ii), and aligning with exiting EE specifications is very
>> important for the platform. Section 6.5.2 in the spec has been updated
>> accordingly.
>>
>> -- Santiago
>>
>>
>
>