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

[jsr339-experts] Re: [jax-rs-spec users] Dynamic Binding Example

From: Bill Burke <bburke_at_redhat.com>
Date: Mon, 05 Nov 2012 13:08:26 -0500

On 11/4/2012 3:27 PM, Marek Potociar wrote:
>
> On Nov 3, 2012, at 3:11 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>
>> Hi,
>>
>> in 6.5.3 in the dynamic binding example there is the line
>>
>> configurable.register(new LoggingFilter());
>>
>>
>> I find it a bit odd that on the one hand, the runtime usually (set aside other DI scopes) will instantiate one instance for every provider. On the other hand, for dynamic binding new instances seem to have to be created.
>
> I wonder where did you get the assumption that "for dynamic binding new instances seem to have to be created"? That's simply not true. Check the Configurable (renamed to Configuration recently) API.
>
>>
>> Is there a JAX-RS construct already to register the global e.g. LoggingFilter instance? And am I just not seeing the forrest for the trees (again)?
>
> If you register a class, it will be registered as a global "singleton" (unless you explicitly register other instances of the class). If you register an instance, it will be registered as a global instance. The thing here is that the providers registered dynamically will be only applied to those methods for which they were registered.
>

I'm assuming we're talking about DynamicFeature:

This is untrue (i hope). If you register a class, container will
allocate an instance for the resource method you're dynamically binding
too. If you register an instance, it will bind it to the particular
resource method whether or not this instance is shared is up to the
application.

>> If so, I'd suggest showing that in the example.
>>
>> If there isn't such a construct, should we have one? Or would one have to use other DI mechanisms instead?
>>
>> E.g. with CDI I could do
>>
>> @Inject
>> LoggingFilter loggingFilter;
>>
>> ...
>> configurable.register(loggingFilter);
>>
>> But having this provided by JAX-RS natively seems nicer.
>
> Once we support JSR330 in JAX-RS, you would be able to do that. (FWIW. you could do that even now with Jersey 2. Without a need for CDI.)
>
>> I guess what I am actually asking for is to add lookup methods for Filters and Interceptors to the Providers interface, right?
>
> I guess so. Perhaps we need to update ResourceContext API? Or perhaps we should just wait for JSR330 integration to get into future JAX-RS release (e.g. 2.1) ...
>

Why do we need lookup methods for filters and interceptors?

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