I personally thing this is a very bad idea.
There are already enough 'config' architectures:
- ant/jmx/bean style, with introspection used to call java bean
setters ( with or without Digester )
- jdk1.4 preferences/JNDI for hierarchical config and components
getting the info themself.
- simple Properties storing data with hierarchical names
Defining another config API and impl - and doing it specifically
for http client is even worse - as it has implications for the
code that would like to use http-client and already has its
own config mechanisms.
I personally think that for components like http client, java-bean
style of configuration is the best and in no case should they
define their own config files and apis.
Except maybe using a common API modeled after jdk1.4 ( similar with
commons-logging ) that wraps jdk1.4 logging, jndi and other
hierarchical-storage configs ( for those who prefer this instead
of setters ).
Costin
Ortwin Glück wrote:
> This is the second iteration in finding the right architecture for the
> preferences API.
> _____
> Notes
> - Moved to a separate package: httpclient.config
> - Configuration is not immutable.
> - Configuration is now hierarchical and reflects changes in underlying
> Configurations immediately.
> - The new ConfigManager links any object with a Configuration instance.
> - If the user does nothing the default configuration is always used.
>
> ___________
> Sample Code
>
> The user can set the configuration from the outside for HttpClient,
> HttpMultiClient, HttpMethod, HttpConnection. The user should not try to
> configure other classes directly:
> --user app
> HttpClient client = new HttpClient();
> Properties patch = new Properties();
> patch.setProperty(ConfigKeys.USER_AGENT, "My HTTP Client 0.01");
> Configuration clientConfig = new Configuration(Configuration.DEFAULT,
> patch);
> ConfigManager.setConfiguration(client, clientConfig);
>
> HttpClient configures HttpMethod automatically IF not yet configured.
> The same way a HttpConnection is configured:
> --HttpClient
> public synchronized int executeMethod(HttpMethod method) {
> ...
> if (!ConfigManager.isConfigured(method)) {
> ConfigManager.setConfiguration(method, myConfig);
> }
> method.execute(getState(), connection);
> ...
> }
>
>
> Low level objects use the configuration of a higher level object. The
> same applies to inner classes:
> --ChunkedInputStream
> myConfig = ConfigManager.getConfiguration(method);
> ... myConfig.getBooleanValue(ConfigKeys.IGNORE_PROTOCOL_VIOLATION);
>
> A static class must be configured by the caller using the meta object.
> Users should never try to configure low-level classes:
> --caller class
> ConfigManager.setConfiguration(NTLM.class, myConfig);
>
> --NTLM
> Configuration myConfig = ConfigManager.getConfiguration(NTLM.class);
> String mySecurityProvider =
> Configuration.getStringValue(ConfigKeys.SECURITY_PROVIDER);
>
>
> ________
> Problems
>
> As you can see this approach generates a large overhead. This is mainly
> caused by one requirement: "Would there be a means to assign my own
> properties object to the HttpClient, HttpConnection and HttpMethod
> objects? So I could control the settings on a "client by client",
> "connection by connection", or "method by method" basis?" by Mark R.
> Diggory, 2002-9-18.
>
> Any single object (e.g. Cookie) must therefore know which Configuration
> applies to it. This means that the creator of an object must set its
> configuration in the ConfigManager. For static classes the requirement
> can not be fulfilled at all. Not so nice, is it.
>
> Please, if any of you has a good idea how to deal with this, drop me a
> note.
>
>
> Odi
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
