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 Wed, 02 Oct 2002 18:00:59 GMT
Jeff Dever wrote:

> I'm torn about this.  I don't think that "bean style" (aka "ass load of
> setters
> and getters") is the answer.  The components in question in HttpClient are
> just
> too big for that to work.  There would be many more _configuration_
> methods in the public interface than anything else.

Then a generic setAttribute ? Or JMX ?

But in general - HttpClient should work as a bean ( or component ) as 
part of a larger program, and support configuration/tunning via API
calls.

Even if a hierarchical pull method is prefered - defining HttpClient's
own config API and/or config file is _bad_ ( and I would -1 it ). 
Either use an existing API ( jndi, properties, etc ), or propose
a top-level commons package ( as a wrapper on top of existing 
solutions ).

Commons component should be easy to integrate in other products and
apps - if they define their own config mechanisms this will be much harder.

Costin


> I think that the configuration that Odi is proposing is a reasonable
> possibility.  The comments that Mark made in a previous email also should 
be
> considered.  I wouldn't exclude a HttpClient customized solution, but if
> there are others, those should be considered too.


 
> As per Mark's email, storing the properties in the respective classes
> themselves
> seems reasonable.  The only problem is making them respect a hierachy. 
> The time that all the components come together (httpmethod, httpstate and
> httpconnection) is in the execute method.  The behavioural properties
> could be checked at the time that execute is called.
> 
> Again, I'm not sure what the right way to go is.
> 
> 
> 
> Costin Manolache wrote:
> 
>> 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>

-- 
Costin



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