jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <p.moua...@ubik-ingenierie.com>
Subject Re: svn commit: r1840406 - in /jmeter/trunk: bin/jmeter.properties src/core/org/apache/jmeter/JMeter.java xdocs/changes.xml xdocs/usermanual/properties_reference.xml
Date Wed, 12 Sep 2018 20:16:33 GMT
Hello Felix,
I reviewed your patch, it looks good to me.

Will you have time to commit it before next RC?
If not, I can.
Regards

On Wednesday, September 12, 2018, Philippe Mouawad <
p.mouawad@ubik-ingenierie.com> wrote:

> I would stick with last Felix patch to respect the KISS principle.
>
> 1 property , and the language detection based on extension looks fairly
> simple for me.
>
> While the other one is not , it will require another bunch of
> documentation and make code more complex only to be able to handle
> initialisation.
>
> Why would one want to use 2 languages for initialising ? Let him choose 1
> language.
>
> Regards
>
> On Mon, Sep 10, 2018 at 1:53 AM sebb <sebbaz@gmail.com> wrote:
>
>> On 9 September 2018 at 16:16, Felix Schumacher
>> <felix.schumacher@internetallee.de> wrote:
>> >
>> >
>> > Am 09.09.2018 um 16:31 schrieb sebb:
>> >>
>> >> On 9 September 2018 at 14:55, Felix Schumacher
>> >> <felix.schumacher@internetallee.de> wrote:
>> >>>
>> >>> Am Sonntag, den 09.09.2018, 14:41 +0100 schrieb sebb:
>> >>>>
>> >>>> On 9 September 2018 at 14:19, Felix Schumacher
>> >>>> <felix.schumacher@internetallee.de> wrote:
>> >>>>>
>> >>>>> While I like groovy, it might be that other users have other
JSR223
>> >>>>> languages as their favourites.
>> >>>>
>> >>>> +1
>> >>>>
>> >>>>> Should we make the init script mechanism a little bit more flexible
>> >>>>> by using
>> >>>>> the files ending to determine the language/engine? That way
a user
>> >>>>> could
>> >>>>> setup a jsr223.init.file=my_suberb_init.js and JMeter would
try to
>> >>>>> get a JSR
>> >>>>> 223 engine for "js", or jsr223.init.file=some_python.py to run
it
>> >>>>> with an
>> >>>>> engine for "py".
>> >>>>>
>> >>>>> What do you think?
>> >>>>
>> >>>> To make it truly generic, I think the startup code needs to be given
>> >>>> a
>> >>>> list of languages to initialise.
>> >>>> After all, someone might want to use two different JSR223 languages.
>> >>>>
>> >>>> One way to do this would be to have the following properties:
>> >>>>
>> >>>> jsr223.init.languages=groovy,js
>> >>>> groovy.init.file=def
>> >>>> js.init.file=abc
>> >>>
>> >>> Yes, that might be a good idea.
>> >>>
>> >>> But I think I might like it better if jsr223.init would be kept in
>> >>> front of those variable names.
>> >>>
>> >>> What do you think of
>> >>>
>> >>> jsr223.init.languages=groovy,js
>> >>> jsr223.init.file.groovy=def
>> >>> jsr223.init.file.js=abc
>> >>
>> >> This will change the behaviour for beanshell unless that is handled
>> >> separately.
>> >
>> > The current behaviour is that beanshell is handled differently.
>> >
>> >>
>> >> Will also need to be aware that BeanShell init could appear in two
>> >> places with different property names and files.
>> >
>> > My English parser seems to be broken, can you elaborate a bit, what you
>> mean
>> > with this?
>>
>> At present there is the property beanshell.init.file
>>
>> AIUI you propose to have the additional property:
>>
>> jsr223.init.file.beanshell=abc
>>
>> What happens if both are defined but point to different files?
>>
>> Whereas with my original naming convention there is only one property
>> name.
>>
>> I'm not saying my suggestion is perfect, but I think it has fewer issues.
>>
>> > Felix
>> >
>> >
>> >>
>> >>> I put the "file" after "init" to enable a potential scripting engine
>> >>> named "languages" ;)
>> >>>
>> >>>> If the code ignored missing *.init.file properties, then
>> >>>> jsr223.init.languages could default to beanshell in order to keep
the
>> >>>> existing behaviour.
>> >>>
>> >>> Well, yes the names would be more appropriate, when .init.file is the
>> >>> postfix. Hm.
>> >>>
>> >>> Felix
>> >
>> >
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
> Ubik-Ingénierie
>
> UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>
>
> UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>
>
>

-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>

UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message