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...
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
>>>>
>>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com