On Nov 3, 2012, at 3:51 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
> Hi,
>
> actually, I am completely confused by the register() variants.
>
> What is the purpose of providing the ability to pass classes and instances to a Configurable or Configuration?
Let me respond with a question: What is the purpose of returning classes and instances from JAX-RS Application sub-class?
>
> I the expectation that a passed class will be instantiated and then registered by the Configurable implementation? Or will it be injected? Or what?
Instantiated and injected. Same as with Application.getClasses.
> Given that all the providers are stateless and usually application scoped, I do not understand why it is not sufficient to have just a single instance and register that.
Providers do not have to be stateless.
>
> I see that I could have a
>
> register( new FooFilter("special value A") ) and soome other register( new FooFilter("special value B") ) but given how the rest of the API works, I'd rather see people doing
>
> register( FooFilterA.class) and register( FooFilterB.class)
>
> Yes, it might save you some conditional blocks in feature implementations
>
> e.g. register( new FooFilter( annotationXy.getValue() )) instead of if(annotationXy.getValue() == ...) { register(...) }
>
>
> , but I wonder who will be able to keep track of the provider instances that end up in ones runtime?
>
That concept works well in Jersey 1.x and we don't see users getting confused. Also, ability to pre-compute provider state once at deploy time may greatly improve performance of some applications.
Marek
> Or, (again) am I missing something?
>
> Jan