[jax-rs-spec users] [jsr339-experts] Re: Name Binding Alignment with CDI

From: Sergey Beryozkin <>
Date: Thu, 24 Jan 2013 09:30:28 +0000

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