http-core and spring

[Stojce Dimski <sd...@yahoo.it>]

Oleg,

What do you mean with 'That would be great to have a Spring 2.0 enabled
module which one could use to assemble various Http components using
Spring's DI framework.' ?

As I think there is nothing special in using http-core with spring,
there is no special needs, http-core components are simple beans and
therefore those are supported out-of-the-box ?
There are some rough corners although, for example in spring apps there
is common sense and convention to wrap parameters in properties files
which are then easily created by beans factories. For using those I had
to write PropertiesHttpParams class which is simple DefaultHttpParams
subclass which in constructor copy all properties from argument object
to itself, so I can use properties beans with spring...
Do you guys think that using just java.util.Properties is not enough for
http-xxx family ? I would prefer to use just Properties instead of
HttpParams simplifying the framework... If we cannot live without
HttpParams then at least let's extend DefaultHttpParams with constructor
which copies all params or make a subclass as I did.
What do you think ?


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

Re: http-core and spring

[Roland Weber <ht...@dubioso.net>]

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

Re: http-core and spring

[Oleg Kalnichevski <ol...@apache.org>]

On Wed, 2007-01-24 at 17:03 +0100, Stojce Dimski wrote:
> Oleg,
> 
> What do you mean with 'That would be great to have a Spring 2.0 enabled
> module which one could use to assemble various Http components using
> Spring's DI framework.' ?
>
> As I think there is nothing special in using http-core with spring,
> there is no special needs, http-core components are simple beans and
> therefore those are supported out-of-the-box ?

Hi Stojce,

Not quite. HttpComponents are just plain old java beans, but some Spring
specific plumbing code may still need to written. For instance, some
custom logic might be required when populating HTTP parameters with
values specified in the Spring context file.

Besides, we should probably take advantage of extensible XML authoring
in Spring 2 and provide custom HttpCore / HttpClient tags (section 2.2.3
[1]).

> There are some rough corners although, for example in spring apps there
> is common sense and convention to wrap parameters in properties files
> which are then easily created by beans factories. For using those I had
> to write PropertiesHttpParams class which is simple DefaultHttpParams
> subclass which in constructor copy all properties from argument object
> to itself, so I can use properties beans with spring...
> Do you guys think that using just java.util.Properties is not enough for
> http-xxx family ? I would prefer to use just Properties instead of
> HttpParams simplifying the framework... If we cannot live without
> HttpParams then at least let's extend DefaultHttpParams with constructor
> which copies all params or make a subclass as I did.
> What do you think ?
> 

The difficulty here is that HTTP parameters are typed. The
HttpComponents framework expects a specific type for some parameters
(Long for timeout values and so on). So, there must be way to convert
textual representation of HTTP parameters stored in an instance
java.util.Properties to corresponding typed values.

Oleg

[1] http://www.springframework.org/docs/reference/new-in-2.html

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