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.
>
> 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.
>
> 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.
Marek