hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: params classes vs. interfaces
Date Sun, 09 Sep 2007 11:12:31 GMT
On Sun, 2007-09-09 at 12:55 +0200, Roland Weber wrote:
> Hi all,
> 
> we currently have classes for defining parameter names and
> utility methods for setting/getting parameters in a set:
> 
> o.a.h.p.HttpConnectionParams
> o.a.h.p.HttpProtocolParams
> o.a.h.nio.p.HttpNIOParams
> o.a.h.auth.p.AuthParams
> o.a.h.cookie.p.CookieSpecParams
> o.a.h.conn.p.HttpConnParams
> o.a.h.client.p.HttpClientParams
> 
> Since all constructors are disabled, it is not possible
> to combine these classes in a hierarchy. I would like to
> move the definition of parameter names into a separate
> set of interfaces, and to arrange these interfaces in a
> hierarchy. And define an interface AllClientParamNames
> (or similar).
> The purpose is to allow users to locate parameters in the
> JavaDocs without being familiar with our "informal unit"
> structure. It's the last API change I have in store for
> core, and it would be a compatible one.
> 
> Please let me know what you think.
> 

I was thinking about trying to do away with those static classes and to
replace them with plain old java beans, so they could be manufactured
using a DI framework such Spring.

Something like o.a.h.p.HttpConnectionParamBean implementing
o.a.h.p.HttpConnectionParams maybe?

Oleg

> cheers,
>   Roland
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message