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