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