hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Defining preferences using properties
Date Fri, 15 Sep 2006 16:00:11 GMT
On 15/09/06, Roland Weber <http-async@dubioso.net> wrote:
> Hi Sebastian,
>
> I don't like locations for configuration data that are evaluated
> unconditionally. I've learned that lesson in OpenCard, once and
> for all :-)

OK, point taken - also there might be two incompatible meanings for
"http.xyz", only one of which applies to HttpClient.

 > I don't mind a package that can be explicitly called
> by an application with a single line of code, though. Like:
>
> HttpParams defaults = ParameterLoader.loadFromSystemProperties();

Yes - except that I was thinking of a property to tell JMeter where to
find the Httpclient property file (if any). This avoids any problems
with name clashes, and allows the override to be optional.

> >> > So: is there any interest in making this part of HttpClient?
> >> >
> >> > And how best to add it?
> >> > - scan for prefixed properties
> >> > - read props from httpclient-specific property file
> >> > - update code to check system property as last resort.
> >> >
> >>
> >> This sounds reasonable. There's a catch, though. A simple properties
> >> file may not be good enough, because some of the HTTP parameters are
> >> typed. So, you will have to devise a mechanism to discover the expected
> >> type for HTTP parameters.
> >
> >
> > There could be an additional "_type" property for values that aren't
> > Strings. e.g.
> >
> > http.socket.timeout=1000
> > _type.http.socket.timeout=Integer
>
> I would have gone for coding the type into the property name:
>
> http.socket.timeout_Integer=1000
>

Good idea.

I'd like to be able to omit the _String suffix for plain strings, as
they are the most common, so it might be necessary to use a format
like:

http.socket.timeout._Integer=1000

to make it less likely that an underscore in an HttpClient property
name could be mistaken for the start of a type. Or perhaps HttpClient
will never use underscores? ;-)

>
> > Some conversions might be trickier than others...
>
> Yes. If property (or XML?) loading requires a type conversion framework,
> we should consider an extra HttpConfig component, either standalone or
> as a module of HttpClient.
>

We already use XStream, which might be useful here.

However, I think the settings that people might want to change would
not be difficult to convert from strings.

S.

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


Mime
View raw message