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

[jsr339-experts] contract parameter for register() methods

From: Bill Burke <bburke_at_redhat.com>
Date: Tue, 19 Feb 2013 10:44:19 -0500

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