On Thu, 2006-09-14 at 18:09 +0100, sebb wrote:
> On 14/09/06, Oleg Kalnichevski <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]