On 15/09/06, Roland Weber <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
