While I agree with Oleg about the purposeful design of the parameters
architecture, I also see that it's not fully compatible with Spring's
approach of composing beans. As an alternative to replacing HttpParams,
we could provide a layer of beans that sit on top of HttpParams. Those
beans might not provide the full flexibility of HttpParams and may have
some limitations, yet offer a simpler way of configuring an HttpClient
instance. What do you think?
Odi
Oleg Kalnichevski wrote:
The existing preferences API based HttpParams [1] was developed in
HttpClient 3.x for a good reason. It allows for a great deal of
flexibility and enables the users to introduce custom parameters without
having to change anything in the stock version of HttpClient. I am
skeptical that plain old java beans could replace it. Having said that I
am open to alternatives and will be happy to review patches
Oleg
[1] http://jakarta.apache.org/commons/httpclient/preference-api.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
