hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject Re: http-core and spring
Date Fri, 26 Jan 2007 23:21:11 GMT
Hi Stojce,

> Do you guys think that using just java.util.Properties is not enough for
> http-xxx family ?

No it is not. As Oleg pointed out, we're storing objects not just strings.
Also, Properties is based on the old Hashtable class which is synchronized
and therefore pointlessly slow. Moreover, we don't have static parents but
dynamic ones. For example, a connection may have parameters from it's
connection manager, but when a request is sent the parameters from the
request will take precedence. We're implementing that by changing the parent
of parameter objects. For example in HttpRequestExecutor.prepareRequest:
	request.getParams().setDefaults(this.params);
In that case, the request specific parameters are augmented by the
request executor's parameters.

If you want to read params from properties files, have a look at JMeter.
Sebastian did some work in that direction:
http://mail-archives.apache.org/mod_mbox/jakarta-httpclient-user/200609.mbox/%3c25aac9fc0609171007g2509edf4u429ca785a9eb2831@mail.gmail.com%3e
http://jakarta.apache.org/jmeter/index.html
I expect a similar extension for properties-based configuration to become
part of HttpComponents in the future, but more likely than not it'll be
the far future.

> it would be very natural to build few simple
> java beans using inheritance and/or composition instead of using actual
> HttpParams...

One HttpParams object can hold parameters for connections, connection
operators, connection managers, request and response interceptors, clients,
dispatchers, and whatever else we'll have in terms of objects that need
to be parameterized. Moreover, we're developing a framework with plenty
of interfaces that can be implemented by custom code which may require
custom parameters.
If we used beans for configuration, we'd have to specify in advance the
set of parameters, or else each implementation class that needs custom
parameters has to come with it's own bean extension - I've seen that kind
of code from a code generator, and it made me shudder. Also we'd have
many different configuration beans, since we wouldn't want a single one
with the getters for each and every parameterizable class.
I've been pondering per-class parameter objects since we discussed the
new preferences architecture years ago. Primarily to get rid of the map
lookups on each use of a parameter. But since the map hierachy is an
integral part of the preferences framework, that would have to go along
with synchronization methods that read the full set of parameters in the
bean from the map, or write modified parameters back to the map. That's
a lot of work, and there's not much point in it. The most frequent uses
of parameters will be related to request processing, and since each
request comes with it's own params you'd have to call the read-from-map
operation each time.
I think that general use configuration beans in the core classes is
a dead end. But if you have a suggestion that might prove me wrong,
I'll give it a fair chance. What I could imagine, if Spring depends on
getters and setters, is an extra layer of beans that can be built by
Spring and which put their values into the parameters map for pickup
by HttpComponents classes. There may also be select cases where
long-lived objects depend on a set of params that will not get
overridden on a case by case basis. Such objects could indeed make use
of configuration beans.

cheers,
  Roland


---------------------------------------------------------------------
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