On 17.04.2012, at 13:39, Marek Potociar wrote:
>
> On Apr 15, 2012, at 10:14 PM, Adam Bien wrote:
>
>>
>> On 16.02.2012, at 16:30, 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
>>
>> The use of @Named as qualifier is already deprecated in the CDI specification. I would use a dedicated qualifier for that.
>
> Nice catch, I didn't know that. Do you know the reason behind this deprecation?+
"3.11. The qualifier @Named at injection points
The use of @Named as an injection point qualifier is not recommended, except in the case of integration with legacy code
that uses string-based names to identify beans."
The reason is: @Named based injection is String based and is not type safe. Custom qualifiers should be preferred.
>
>> An alternative: using the InjectionPoint as parameter in the Producer could work as well.
>
> I am not a CDI expert, can you please elaborate a bit more?
e.g.
@Produces
public String getInt(InjectionPoint ip){
Class clazz = ip.getMember().getDeclaringClass();
String memberName = ip.getMember().getName();
System.out.println("-Fully qualified name of the injected attribute is: -- " + clazz.getName() + "." +memberName);
return configurationSource.get(clazz.getName()+"."+memberName);
}
With the InjectionPoint you get access to the name and type of the injection point.
>
> Marek
>
>>
>>
>>>>
>>>> ...
>>>> }
>>>>
>>> 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
>>
>