You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Costin Manolache <cm...@yahoo.com> on 2002/10/01 21:27:04 UTC
Re: [HttpClient] Preferences Architecture Implementation Draft II
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [HttpClient] Preferences Architecture Implementation Draft II
Posted by Costin Manolache <cm...@yahoo.com>.
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:
>> <ma...@jakarta.apache.org> For additional
>> commands, e-mail: <ma...@jakarta.apache.org>
--
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [HttpClient] Preferences Architecture Implementation Draft II
Posted by Jeff Dever <js...@sympatico.ca>.
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [HttpClient] Preferences Architecture Implementation Draft II
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: news [mailto:news@main.gmane.org] On Behalf Of Costin Manolache
> Sent: 01 October 2002 20:27
> To: commons-dev@jakarta.apache.org
> Subject: Re: [HttpClient] Preferences Architecture Implementation
Draft II
>
> I personally thing this is a very bad idea.
I agree.
>
> 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.
+1
>
> 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 ).
Please use the javabeans approach. HttpClient should remain a framework
and not an application. Also, please use the Inversion of Control
pattern as much as possible to make the framework as flexible as
possible.
Thanks Costin.
-Vincent
[snip]
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>