commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Dever <jsde...@sympatico.ca>
Subject Re: [HttpClient] Preferences Architecture Implementation Draft II
Date Tue, 01 Oct 2002 21:35:04 GMT
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.

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>


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