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