On 12/14/2011 01:36 PM, Bill Burke wrote:
>
>
> On 12/14/11 4:40 AM, Marek Potociar wrote:
>>
>>
>> On 12/13/2011 07:24 PM, Bill Burke wrote:
>>> I think you missed this in my previous note, but the Configuration interface is too complex to have to implement for an
>>> application developer as there is a lot of logic that would be needed to implement disable/enable/update. Either this
>>> needs to be turned into a class, or Configuration needs to be greatly simplified.
>>
>> Why would an average application developer implement the Configuration class? This is meant to be implemented by the
>> client provider. Btw. one relatively easy way to implement this is to take existing impl e.g. from RI and wrap it into a
>> custom impl.
>>
>
> Um, because ClientFactory has a newClient(Configuration) method so that you can initialize the client? App developers
> are going to be using this class about as much as they use the Application class. No?
>
> Or
>
> Just remove the ClientFactory.newClient(Configuration) method so users cant't call it. Then Configuration becomes
> something owned by the container. (Please no more builder interfaces though!!!!!!!!!!!!!!!)
The intended use case for CF.newClient(Configuration) was to enable to initialization a new client with an existing
config, e.g.:
Client c1 = ClientFactory.newClient();
Target t = c1....
... some config changes in client or target over time...
Client c2 = ClientFactory.newClient(t.configuration());
or
Client c2 = ClientFactory.newClient(c1.configuration());
>
>>>
>>> What I would prefer is that Configuration becomes very simple and disable/enable/update/property methods are moved to
>>> the Client interface:
>>>
>>> interface Configuration {
>>> Set<Class<?>> getProviderClasses();
>>> Set<Object> getProviderInstances();
>>> Map<String, Object> getProperties();
>>> }
>>
>> I smell concurrency issues. In addition, this move would greatly reduce the current flexibility of the interface. The
>> idea was to be able to create only one or very few expensive client objects and then leverage configuration inheritance
>> to fine-tune the configuration. I would really have hard time to give up on this one.
>>
>
> I don't see how the refactoring doesn't allow what you want or how it creates concurrency issues. In other words, it
> doesn't. The implementation could make a copy of the Configuration class, or you could just not expose the
> Configuration interface through the getConfiguration() method and just have get/setproperty enable/disable there.
>
>>>
>>> and move register(), disable() et. al. to the Client interface and not expose Configuration there:
>>>
>>> interface Client {
>>>
>>> setProperty(...);
>>> register(...);
>>> }
>>>
>>> There's really 2 reasons why I want it this way.
>>> * I want the container to have full control over how disable/register/update etc. are implemented. I don't want the
>>> user to be able to override these methods. I don't want the spec to implement them either.
>>>
>>> * Configuration becomes more akin to Application. A simple interface for specifying what is bound.
>>
>> The huge difference is that with server-side Application there are other means how to customize providers on each
>> resource. This is not possible on the client side, which is why I am against the proposed simplification. I do not want
>> to force users to create a new client instance each time they need a slightly different set of filters for a single
>> request.
>>
>
> It all depends if you expect the user to configure Client interfaces via a Configuration object passed to
> CLientFactory.newClient(Configuration). If thats the usage scenario you expect I'm shocked you don't see the complexity
> it adds to the user. The contract defined within Configuration is complex for the app developer to implement.
>
I'm sorry for putting you in a shock, but I still don't understand the issue. No one is forcing developers to create
configuration instances by themselves. Can you provide a concrete example of the problem you see?
Marek