You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by sebb <se...@gmail.com> on 2006/09/14 15:15:49 UTC
Defining preferences using properties
Just wondering if there are any plans to allow default preferences to
be picked up from java properties?
So for example, one could define
http.protocol.element-charset=ISO-8859-1
and have that automatically added as the default preference.
An application can of course do this itself, by scanning the system
properties looking for any with the appropriate prefix, or it could
process an httpclient.properties file.
But it might be useful to be able to change the preferences without
needing to write any application code. For example, for embedded
applications.
We're probably going to have to do this anyway for JMeter; of course
the code could be added to HttpClient if it was thought useful (e.g.
we could provide patches).
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.
S///
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Defining preferences using properties
Posted by sebb <se...@gmail.com>.
On 17/09/06, Roland Weber <ht...@dubioso.net> wrote:
> Hi Sebastian,
>
> > Qualified classnames for the conversion makes it harder to use.
> >
> > Given that there aren't many different types, I'm intending to use a
> > simple naming convention that is documented in an example parameters
> > file.
>
> I was thinking ahead for the future. We don't know what kind of
> parameters may be required in the future. Arrays of MessageFormat
> to parse dates in cookies, for example?
>
It's unlikely these will need to be overridden by the casual user.
I've now added an option to run a BeanShell script at start-up, if
necessary the user can write the Java code to set up the defaults
directly.
> > It is easy enough for the user to look at the parameter page and work
> > out the corresponding property name.
>
> Sure. I still recommend $int rather than $Integer :-)
>
I went with the types as shown in the preference api documentation.
> > But if you are considering adding something to HttpClient, then
> > perhaps it would be worth considering some form of parameter name +
> > type registry, perhaps via annotations. This information could be used
> > to validate parameters, and the list could be compared against the
> > user documentation. Or maybe the documentation could be generated from
> > the annotations?
>
> I doubt we'll have spare time for that before 2008.
>
OK.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Defining preferences using properties
Posted by Roland Weber <ht...@dubioso.net>.
Hi Sebastian,
> Qualified classnames for the conversion makes it harder to use.
>
> Given that there aren't many different types, I'm intending to use a
> simple naming convention that is documented in an example parameters
> file.
I was thinking ahead for the future. We don't know what kind of
parameters may be required in the future. Arrays of MessageFormat
to parse dates in cookies, for example?
> It is easy enough for the user to look at the parameter page and work
> out the corresponding property name.
Sure. I still recommend $int rather than $Integer :-)
> But if you are considering adding something to HttpClient, then
> perhaps it would be worth considering some form of parameter name +
> type registry, perhaps via annotations. This information could be used
> to validate parameters, and the list could be compared against the
> user documentation. Or maybe the documentation could be generated from
> the annotations?
I doubt we'll have spare time for that before 2008.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Defining preferences using properties
Posted by sebb <se...@gmail.com>.
On 16/09/06, Roland Weber <ht...@dubioso.net> wrote:
> Hi Sebastian,
>
> > Agreed; $ would be better than _ or ._, so I propose to use it, e.g.
> >
> > http.socket.timeout$Integer=1000
>
> One little detail: it might be easy to prepend java.lang. to Integer,
> but I would still prefer a different scheme. My suggestion: if the
> type is given as a classname, it must be fully qualified (and there
> is no support for classes outside of a package). To make things easy
> for the elementary types, these are mapped to the corresponding class
> in java.lang., like Java itself does in reflections and elsewhere.
> So the following two would be interpreted in the same way:
>
> http.socket.timeout$int=1000
> http.socket.timeout$java.lang.Integer=1000
>
> The default type is java.lang.String, so these are equivalent:
>
> http.whatever.string.param=value
> http.whatever.string.param$java.lang.String=value
>
Qualified classnames for the conversion makes it harder to use.
Given that there aren't many different types, I'm intending to use a
simple naming convention that is documented in an example parameters
file.
It is easy enough for the user to look at the parameter page and work
out the corresponding property name.
Obviously a mapping of parameter names to types would mean that the
conversion type could be omitted, but this was intended to be a simple
means for JMeter users to override one or two parameters, so I think
I'll go with my original plan.
==
But if you are considering adding something to HttpClient, then
perhaps it would be worth considering some form of parameter name +
type registry, perhaps via annotations. This information could be used
to validate parameters, and the list could be compared against the
user documentation. Or maybe the documentation could be generated from
the annotations?
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Defining preferences using properties
Posted by Tatu Saloranta <co...@yahoo.com>.
--- Roland Weber <ht...@dubioso.net> wrote:
> Hello Tatu,
>
...
> > type), or by user of the parameter specifying it
> > with access (getIntParameter() etc).
>
> We don't have beans, we have a simple hash map. It
> s supposed to be quick, so we don't to type
> conversions
> at runtime, except for Integer.intValue() and such.
Ok. That pretty much answers my question then.
> If you use getIntParameter(name) and the value is
> not an Integer, there will be an exception. No lazy
> parsing of String to int.
Thanks,
-+ Tatu +-
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Defining preferences using properties
Posted by Roland Weber <ht...@dubioso.net>.
Hello Tatu,
> A quick question: I am probably missing something, but
> is it really necessary to use explicit typing in
> configuration files? In many cases, one can infer the
> type either via bean-style introspection (mapping
> parameter name to field or method name, which has
> type), or by user of the parameter specifying it with
> access (getIntParameter() etc).
We don't have beans, we have a simple hash map. It is
supposed to be quick, so we don't to type conversions
at runtime, except for Integer.intValue() and such.
If you use getIntParameter(name) and the value is not
an Integer, there will be an exception. No lazy parsing
of String to int.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Defining preferences using properties
Posted by Tatu Saloranta <co...@yahoo.com>.
--- Roland Weber <ht...@dubioso.net> wrote:
> Hi Sebastian,
>
> > Agreed; $ would be better than _ or ._, so I
> propose to use it, e.g.
> >
> > http.socket.timeout$Integer=1000
>
> One little detail: it might be easy to prepend
> java.lang. to Integer,
> but I would still prefer a different scheme. My
...
> http.whatever.string.param=value
> http.whatever.string.param$java.lang.String=value
>
>
> Oleg, you mentioned that you would prefer a separate
> mapping of
> parameter names to types instead of encoding the
> type directly
A quick question: I am probably missing something, but
is it really necessary to use explicit typing in
configuration files? In many cases, one can infer the
type either via bean-style introspection (mapping
parameter name to field or method name, which has
type), or by user of the parameter specifying it with
access (getIntParameter() etc).
-+ Tatu +-
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Defining preferences using properties
Posted by Roland Weber <ht...@dubioso.net>.
Hi Sebastian,
> Agreed; $ would be better than _ or ._, so I propose to use it, e.g.
>
> http.socket.timeout$Integer=1000
One little detail: it might be easy to prepend java.lang. to Integer,
but I would still prefer a different scheme. My suggestion: if the
type is given as a classname, it must be fully qualified (and there
is no support for classes outside of a package). To make things easy
for the elementary types, these are mapped to the corresponding class
in java.lang., like Java itself does in reflections and elsewhere.
So the following two would be interpreted in the same way:
http.socket.timeout$int=1000
http.socket.timeout$java.lang.Integer=1000
The default type is java.lang.String, so these are equivalent:
http.whatever.string.param=value
http.whatever.string.param$java.lang.String=value
Oleg, you mentioned that you would prefer a separate mapping of
parameter names to types instead of encoding the type directly
in the parameter definitions. My main concern is that we would
have to maintain a type mapping that potentially spans across
all components. Application developers that want to use additional
parameters in their implementations would need to extend that
mapping.
While that can be managed by having multiple mapping lists, one
for each component and additional ones for applications that want
to define their own parameters, this seems to be a complex setup
that IMHO we should rather not tackle at this time.
Encoding the type into a property name is a direct equivalent
of the way HttpParams is currently used in the code:
params.setParameter("http.socket.timeout", new Integer(1000));
params.setIntParameter("http.socket.timeout", 1000);
params.setParameter("http.socket.timeout", "1000"); // BAD!
There is no type check here either. Having an implementation
of HttpParams that performs type checks is something I would
consider a future extension, just like a preferences scheme
with separate type mapping.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Defining preferences using properties
Posted by sebb <se...@gmail.com>.
On 15/09/06, Roland Weber <ht...@dubioso.net> wrote:
> Hi Sebastian,
[...]
>
> 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 @.
Agreed; $ would be better than _ or ._, so I propose to use it, e.g.
http.socket.timeout$Integer=1000
[...]
Sebastian
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Defining preferences using properties
Posted by Roland Weber <ht...@dubioso.net>.
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: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Defining preferences using properties
Posted by sebb <se...@gmail.com>.
On 15/09/06, Roland Weber <ht...@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
Re: Defining preferences using properties
Posted by Roland Weber <ht...@dubioso.net>.
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 :-) 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();
>> > 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
> 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.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Defining preferences using properties
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2006-09-14 at 18:53 +0100, sebb wrote:
> On 14/09/06, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Thu, 2006-09-14 at 18:09 +0100, sebb wrote:
> [...]
>
> > > There could be an additional "_type" property for values that aren't
> > > Strings. e.g.
> > >
> > > http.socket.timeout=1000
> > > _type.http.socket.timeout=Integer
> > >
> > > Some conversions might be trickier than others...
> > >
> >
> > It just thought that a map of parameter names to a corresponding
> > instance of java.beans.PropertyEditor might be the most elegant solution
> > to this problem.
> >
> > Map paramEditorMap = new HashMap();
> > paramEditorMap.put("type.http.socket.timeout", new IntegerEditor());
> >
>
> Not sure I understand how to use the IntegerEditor() here - I thought
> the PropertyEditor classes were intended for GUIs only?
>
Sun messed up big time by having made java.beans.PropertyEditor
dependent on some AWT interfaces. Nonetheless, this does make property
editors less useful and certainly does not prevent you from using them
in a non-visual mode to convert beans to their textual representation
and back. For instance, Spring makes a very heavy use of property
editors.
> Also, this means knowing all the (non-String) property names in
> advance, even if they are not needed...
Personally I would rather have it this way than have to specify the
parameter type in the config file.
Anyways, take it for what it is worth
Cheers
Oleg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Defining preferences using properties
Posted by sebb <se...@gmail.com>.
On 14/09/06, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2006-09-14 at 18:09 +0100, sebb wrote:
[...]
> > There could be an additional "_type" property for values that aren't
> > Strings. e.g.
> >
> > http.socket.timeout=1000
> > _type.http.socket.timeout=Integer
> >
> > Some conversions might be trickier than others...
> >
>
> It just thought that a map of parameter names to a corresponding
> instance of java.beans.PropertyEditor might be the most elegant solution
> to this problem.
>
> Map paramEditorMap = new HashMap();
> paramEditorMap.put("type.http.socket.timeout", new IntegerEditor());
>
Not sure I understand how to use the IntegerEditor() here - I thought
the PropertyEditor classes were intended for GUIs only?
Also, this means knowing all the (non-String) property names in
advance, even if they are not needed...
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Defining preferences using properties
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2006-09-14 at 18:09 +0100, sebb wrote:
> On 14/09/06, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Thu, 2006-09-14 at 14:15 +0100, sebb wrote:
> > > Just wondering if there are any plans to allow default preferences to
> > > be picked up from java properties?
> > >
> > > So for example, one could define
> > >
> > > http.protocol.element-charset=ISO-8859-1
> > >
> > > and have that automatically added as the default preference.
> > >
> > > An application can of course do this itself, by scanning the system
> > > properties looking for any with the appropriate prefix, or it could
> > > process an httpclient.properties file.
> > >
> > > But it might be useful to be able to change the preferences without
> > > needing to write any application code. For example, for embedded
> > > applications.
> > >
> > > We're probably going to have to do this anyway for JMeter; of course
> > > the code could be added to HttpClient if it was thought useful (e.g.
> > > we could provide patches).
> > >
> >
> > Hi Sebastian,
> >
> > This issue has been discussed a while ago and the decision has been made
> > that HttpClient may not use (1) system properties and (2) configuration
> > files of any sort.
> >
> > There is, however, a mechanism allowing for an easy customization of the
> > way HttpClient gets initialized with default parameters: just provide a
> > custom implementation of the HttpParamsFactory interface and plug it
> > into the DefaultHttpParams.
>
> Yes, I'd seen that, but as far as I can tell it's easier just to
> update the defaults directly.
>
> > > 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
>
> Some conversions might be trickier than others...
>
It just thought that a map of parameter names to a corresponding
instance of java.beans.PropertyEditor might be the most elegant solution
to this problem.
Map paramEditorMap = new HashMap();
paramEditorMap.put("type.http.socket.timeout", new IntegerEditor());
Oleg
> > Please let me know if there is anything I could be of help with to the
> > JMeter project.
>
> Thanks!
>
> By the way, the reason this came up was someone reported that a Cookie
> was being changed by HttpClient, and not by the default Java http
> implementation.
>
> Setting http.protocol.element-charset=ISO-8859-1 fixed the problem in
> my testing; but of course I had to update the JMeter code to do this
> (or I could have used BeanShell as I realised afterwards...)
>
> S.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Defining preferences using properties
Posted by sebb <se...@gmail.com>.
On 14/09/06, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2006-09-14 at 14:15 +0100, sebb wrote:
> > Just wondering if there are any plans to allow default preferences to
> > be picked up from java properties?
> >
> > So for example, one could define
> >
> > http.protocol.element-charset=ISO-8859-1
> >
> > and have that automatically added as the default preference.
> >
> > An application can of course do this itself, by scanning the system
> > properties looking for any with the appropriate prefix, or it could
> > process an httpclient.properties file.
> >
> > But it might be useful to be able to change the preferences without
> > needing to write any application code. For example, for embedded
> > applications.
> >
> > We're probably going to have to do this anyway for JMeter; of course
> > the code could be added to HttpClient if it was thought useful (e.g.
> > we could provide patches).
> >
>
> Hi Sebastian,
>
> This issue has been discussed a while ago and the decision has been made
> that HttpClient may not use (1) system properties and (2) configuration
> files of any sort.
>
> There is, however, a mechanism allowing for an easy customization of the
> way HttpClient gets initialized with default parameters: just provide a
> custom implementation of the HttpParamsFactory interface and plug it
> into the DefaultHttpParams.
Yes, I'd seen that, but as far as I can tell it's easier just to
update the defaults directly.
> > 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
Some conversions might be trickier than others...
> Please let me know if there is anything I could be of help with to the
> JMeter project.
Thanks!
By the way, the reason this came up was someone reported that a Cookie
was being changed by HttpClient, and not by the default Java http
implementation.
Setting http.protocol.element-charset=ISO-8859-1 fixed the problem in
my testing; but of course I had to update the JMeter code to do this
(or I could have used BeanShell as I realised afterwards...)
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Defining preferences using properties
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2006-09-14 at 14:15 +0100, sebb wrote:
> Just wondering if there are any plans to allow default preferences to
> be picked up from java properties?
>
> So for example, one could define
>
> http.protocol.element-charset=ISO-8859-1
>
> and have that automatically added as the default preference.
>
> An application can of course do this itself, by scanning the system
> properties looking for any with the appropriate prefix, or it could
> process an httpclient.properties file.
>
> But it might be useful to be able to change the preferences without
> needing to write any application code. For example, for embedded
> applications.
>
> We're probably going to have to do this anyway for JMeter; of course
> the code could be added to HttpClient if it was thought useful (e.g.
> we could provide patches).
>
Hi Sebastian,
This issue has been discussed a while ago and the decision has been made
that HttpClient may not use (1) system properties and (2) configuration
files of any sort.
There is, however, a mechanism allowing for an easy customization of the
way HttpClient gets initialized with default parameters: just provide a
custom implementation of the HttpParamsFactory interface and plug it
into the DefaultHttpParams.
> 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.
Please let me know if there is anything I could be of help with to the
JMeter project.
Oleg
> S///
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org