jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emilian Bold <emilian.b...@gmail.com>
Subject Re: Checking values of properties more thoroughly
Date Sun, 16 Jul 2017 14:25:03 GMT
> The getPropDefault looks for values inside text files and tries to find one matching the
name of the first argument. If it can't find one, it gives back the default value (which is
the second argument).

The text file is an implementation detail. The API getPropDefault
should allow me to think the value is validated already.

>> RemoteJMeterEngineImpl.startServer(JMeterUtils.getPropDefault("server_port", 0));
> Than this is more an argument against this specific usage of getPropDefault, isn't it?

Well, yes, it is rare to have non-constants.

> Where would you register/configure the validators?

Via annotations would be the most simple. Some service registration
would work too.

> What happens with third party modules, that would want to be checked, too?

Third party modules that define their own properties should do their
own validation. If they just use official JMeter properties, they
should expect the getPropDefault API call to return valid values.

> How would you integrate these annotations into our codebase?

I think the most "basic" way would be with code generation. Use the
annotations but then generate code with an annotation processor. The
generated code would be used to validate the properties file at
startup.


--emi


On Sun, Jul 16, 2017 at 5:10 PM, Felix Schumacher
<felix.schumacher@internetallee.de> wrote:
> Am 16.07.2017 um 15:59 schrieb Vladimir Sitnikov:
>>
>> Emilian>The reason being that I expect getPropDefault to already return a
>> valid value or *my* default which I also know it's valid.
>>
>> +1
>>
>>
>> Emilian>A solution would be to validate the whole configuration file at
>> start up.
>>
>> There always might be "runtime validations", so we can't rely on "validate
>> everything at startup time".
>>
>> JMeter has lots of features and lots of options. Should it warn user if
>> some unused feature is misconfigured?
>>
>> Alternative (additional) option is to define properties via  some
>> class-interface like entities.
>> That is tie validator to the property, and not to the call site.
>
> Something like find all classes with interface PropertyValidatorInitializer
> (or something like that) and run them on startup. These classes could
> register (in a central registry) validators for property names.
>
> Than getPropDefault (or other getProp-variants) could ask the central
> registry to validate the values and even give specific error messages on
> failure.
>
>>
>> Note: "string -> whatever" conversion might need to use original string
>> value in order to make error message clear.
>>
>> Do you think error messages should be localizable?
>
> Might be nice, so I think it would definitely be a plus.
>>
>> Do you think error messages should refer to the relevant documentation
>> sections and/or provide corrective actions?
>
> Would be nice, too.
>
> Felix
>
>>
>> PS. Here's a relevant quote:
>> https://twitter.com/mezzoblue/status/878336246996647938
>>
>> Vladimir
>>
>

Mime
View raw message