Hi Sebastian, >> 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.
No problem. Once you have the code that converts from java.util.Properties (though I prefer java.util.Map), you can plugin in any kind of front end to load those properties from anywhere. >> > 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 Sure. > 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? ;-) I think we can arrange for parameter names without underscores. We've never used them so far, we can officially declare them as banned for the future. Or we reserve some other character even less likely to be used in keys for this purpose, like $ or @. >> > 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. XStream configuration sounds like a nice thing for a contrib package :-) I wouldn't want the dependency in the supported code, especially since it seems to introduce transitive dependencies. > However, I think the settings that people might want to change would > not be difficult to convert from strings. I also think that a set of string name/value pairs should be the first choice for this kind of functionality. It's easy to adapt for different input formats like properties files, XML SAX or DOM, java.util.prefs.Preferences,... cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
