Mailing-List: contact httpclient-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of sebbaz@gmail.com designates
 64.233.184.239 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Z3JbI7gXXtMGicjiHhUlJEM/t/84z5anS08kn6B4DwS6TTfZL4qItfSwTQRfCxz8XKKaK5Lu4ILyuovM1XKpQLIV9frLpocPFsicSg2kCmR8ph8TU+Y5cd0VxU4ySaF15PyrnBszlboQSQLA+FY7B2izaQIfukWgbQUOHAQvxDM=
Message-ID: <25aac9fc0609150900g3c3391c8vfc75e79deb36e45f@mail.gmail.com>
Date: Fri, 15 Sep 2006 17:00:11 +0100
From: sebb <sebbaz@gmail.com>
To: "HttpClient User Discussion" <httpclient-user@jakarta.apache.org>
Subject: Re: Defining preferences using properties
In-Reply-To: <450AA2A4.7030808@dubioso.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <25aac9fc0609140615u375028ffw4061ee26aebec8bf@mail.gmail.com>
	 <1158249524.4959.29.camel@localhost.localdomain>
	 <25aac9fc0609141009i17a09f6vb08a55d79a64977@mail.gmail.com>
	 <450AA2A4.7030808@dubioso.net>

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