commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: [HttpClient] Preferences Architecture Implementation Draft II
Date Tue, 01 Oct 2002 19:27:04 GMT
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:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message