On Thu 16 Feb 2012 05:56:13 PM CET, Bill Burke wrote:
>
>
> On 2/16/12 9:38 AM, 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>.
>>
>
> Ya, but
>
> a) It is highly complex to implement the entire Configuration interface. Its what I complained about before...
I am looking at possible simplifications (as promised earlier).
>
> b) It is way too much a burden to require developers to implement ContextResolver just to be able to allocate a Client
> (or Target). Maybe it would be better to use CDI to inject Clients?
You would not need to do that. Only if you wanted to pre-configure
these. As for CDI, not sure what you have in mind.
Marek
>
> Bill
>