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:[EMAIL PROTECTED]> For additional
>> commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Costin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
