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...
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?
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com