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

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Client initialization on server-side

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Thu, 16 Feb 2012 16:48:05 +0100

On Thu 16 Feb 2012 04:30:32 PM CET, Sergey Beryozkin wrote:
> Hi
> On 16/02/12 14:38, Marek Potociar wrote:
>>
>>
>> On 02/16/2012 03:11 PM, Santiago Pericas-Geertsen wrote:
>>>
>>> On Feb 15, 2012, at 5:40 AM, Marek Potociar wrote:
>>>
>>>> I lean towards the option of registering custom Configuration of the
>>>> Target as part of the @Uri annotation somehow (configuration
>>>> provider?). The data from the provided custom configuration instance
>>>> would be used only for initial configuration, IOW the instance would be
>>>> read-only (and thus could be simple).
>>>
>>> So, no class scanning and just a simple way to obtain the desired configuration? Did you mean a configuration
>>> provider or a resolver as in ContextResolver<Configuration>?
>>
>> I was thinking of a dedicated configuration provider, but anything that implements ContextResolver<Configuration> would
>> work just fine. With that, it should be possible to use the standard server-side provider lookup/registration mechanism
>> and select the first available provider implementing ContextResolver<Configuration>.
>>
>> Note that once we enable support for javax.inject.Qualifier, we could also use it for matching config resolvers to
>> concrete injection points, e.g.:
>>
>> @Named("cfg-a")
>> @Provider
>> public class ConfigResolverA implements ContextResolver<Configuration> { ... }
>>
>> public class Resource {
>> @Uri @Named("cfg-a") Target t; // configuration provided by ConfigResolverA
>>
>> ...
>> }
>>
> This won't probably work in OSGI though, because the runtime won't have the ConfigResolverA class visible...

Why?? If all the custom providers are visible, why not this one?

Marek

> Can we have just
> '_at_Uri Target t'
> and associate the configuration provider somehow else ? Perhaps @Uri itself should have a Class property - this will
> also avoid the visibility issues
>
> Sergey
>
>
>>
>> We may also be able to reuse the proposed filter binding annotation for this...
>>
>> Marek
>>
>>>
>>> -- Santiago
>>>
>>>>
>>>> On Tue 14 Feb 2012 08:52:39 PM CET, Bill Burke wrote:
>>>>>
>>>>>
>>>>> On 2/14/12 1:54 PM, Santiago Pericas-Geertsen wrote:
>>>>>>
>>>>>> On Feb 14, 2012, at 12:40 PM, Bill Burke wrote:
>>>>>>
>>>>>>>>
>>>>>>>> Could you comment on [1] to keep track of this?
>>>>>>>>
>>>>>>>> -- Santiago
>>>>>>>>
>>>>>>>> [1] http://java.net/jira/browse/JAX_RS_SPEC-170
>>>>>>>>
>>>>>>>
>>>>>>> FYI, I think this is a blocker issue as it will be impossible to
>>>>>>> support scanning without some way of designating a filter/interceptor
>>>>>>> as client or server only. I made some comments on the issue.
>>>>>>
>>>>>> I added a comment as well. I'm trying to understand what is the
>>>>>> environment and scope for this feature. There's two parts: (i) injection
>>>>>> and (ii) configuration. Is injection allowed in all JAX-RS managed
>>>>>> beans, EE managed beans, CDI beans, etc? What is the scope of the class
>>>>>> scanning process? What about a plain SE app?
>>>>>>
>>>>>
>>>>> Its not just an injection issue. If you have a WAR that is scanned, how is the scanner supposed to determine whether
>>>>> a @Provider filter/interceptor should be registered or not? Currently, if you have a client-only filter/interceptor,
>>>>> it *will* be registered autmoatically.
>>>>>
>>>>> Bill
>>>>>
>>>
>
>