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

[jsr339-experts] Re: [jax-rs-spec users] contract parameter for register() methods

From: Bill Burke <bburke_at_redhat.com>
Date: Wed, 20 Feb 2013 10:05:19 -0500

I've complained about this before, but since I'm finally writing about
this and not just implementing I've got better reasons for my arguments.

On 2/20/2013 8:47 AM, Marek Potociar wrote:
> Bill,
>
> At this point (today I'm releasing PFD version of the API) I am reluctant to get involved in any discussions about removals of parts of API that should have been reviewed long time ago. There's nothing wrong with the method. It's not a bug in the API.
>
> Marek
>
> On Feb 19, 2013, at 4:44 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>> The register() methods in Configurable that take a list of contracts should be removed. i.e.
>>
>> public C register(Class<?> componentClass, Class<?>... contracts);
>>
>> When you have a class that implements multiple interfaces, its usually to share initialization code and also to make coordination of a complex feature easier between the various component layers. It would be *extremely* rare (I would say never) for a user to want to partially deploy a class.
>>
>> As it is, this is a method I'm not going to document in my book as I just don't see it ever being used. Not only that, but I think it is a very bad practice to have a class that can have parts that are optionally deployable. If the user wants this capability then they should create a class hierarchy and deploy that way.
>>
>>
>> I have similar less-strong feelings about this method:
>>
>> register(Class component, Map<Class, Integer>)
>>
>> Instead of having this method, why not ditch the idea of reusing javax.annotation.Priority, and have our own priority annotation that could be applied to a method? i.e.
>>
>> public class MyFilter implements ContainerRequestFilter, ContainerResponseFilter {
>>
>> @Priority(1)
>> public void filter(ContainerRequestContext ctx) {...}
>>
>> @Priority(5)
>> public void filter(ContainerRequestContext request, ContainerRequestContext response) {...}
>> }
>>
>>
>> Or...Require that the user break up the class into a class hierarchy if they want different priorities.
>>
>> In summary, we're bloating the API for use cases that are extremely questionable in terms of their usefulness and whether or not its really a good practice to allow such a design.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com