On Nov 5, 2012, at 7:08 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> 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.
The idea was here to manage these providers as singletons unless explicitly stated otherwise (as with any other class-based JAX-RS providers).
> 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.
Yes, again, this is same as with any other instance-based JAX-RS providers.
>
>>> 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?
I let Jan respond to that as I don't see the full use case he has in mind.
Marek
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com