Bloating the spec for very narrow use cases is generally not a good
idea, but whatever Marek. I can't wait to not have to argue with you
anymore... :) I won't submit any comments anymore since, it seems, the
spec is closed. You might as well just dissolve the expert group.
And I don't apologize at all for submitting a flurry of minor
suggestions and removal requests. I've been spending the past year
implementing JAX-RS 2.0, now I'm focused on documenting it (through my
book). You see things very differently when writing about an API.
On 2/20/2013 8:50 AM, Marek Potociar wrote:
> I can only repeat myself. We're past the point of removing and adding pieces of API just because you are "not a big fan" of them. This API has been discussed at length and often offers a simple and nice way for binding providers.
>
> Marek
>
> On Feb 20, 2013, at 12:03 AM, Bill Burke <bburke_at_redhat.com> wrote:
>
>> If your annotation has a qualifier, then @NameBinding really isn't a very efficient pattern to implement a filter or interceptor. For example, let's say you had a @MaxAge annotation that triggered adding a Cache-Control header with a qualified max-age:
>>
>> @MaxAge(100)
>> @GET
>> public String get() {...}
>>
>> The @NameBinding filter would have to inject ResourceInfo and look up the @MaxAge annotation each and ever request to set the value. It is much better to implement a DynamicFeature in this case so you can pre-initialize the filter with the annotation's value.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com