Jeff Dever wrote:
> Hey Odi,
>
> I just made a few minor additions.
Included.
> We also have to be careful of the
> NumberFormatExceptions that will be thrown by the parseInt() type calls.
> Perhaps there should be a ConfigurationException?
Yes I was thinking about this as well. "Problem" here: you have to catch
those ConfigurationExceptions somewhere (looks ugly) or make
ConfigurationException a RuntimeException.
> Also I think that these
> related classes should be in their own package, such as httpclient.config.
Yes why not.
> I am a little concerned about the use of the configuration object. I would
> expect calls to this to look like:
>
> String httpVersion = config.getStringValue("http.version");
>
> It seems a little verbose if it has to be used frequently.
True but I don't see a shorter way to do it really. Do you? Of course we
could use shorter method names...
> At the same
> time, we will have to be careful not to "cache" these values in case a user
> changes the config value during runtime.
I really have to think the architecture over again. Maybe Configuration
will not be immutable.
We need one Configuration instance that can be shared among HttpClient
or a HttpConnection and its Methods. This OR makes things really
difficult. Who should hold the configuration object? I don't want the
user having to supply a Configuration object. He should only need to
supply Properties (patches) if needed.
Making it a singleton does not help because we may want several
HttpClients that use different settings.
> I think that this is a pretty good start. There are some bugs for
> configuration that are already opened:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=10790
> http://issues.apache.org/bugzilla/show_bug.cgi?id=10791
> http://issues.apache.org/bugzilla/show_bug.cgi?id=10797
>
> These bugs are targeted for HttpClient 2.1. Question: do people want this
> in the 2.0 release?
I want it :-)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
