Am 09.09.2018 um 16:31 schrieb sebb:
On 9 September 2018 at 14:55, Felix Schumacher
<[email protected]> wrote:
Am Sonntag, den 09.09.2018, 14:41 +0100 schrieb sebb:
On 9 September 2018 at 14:19, Felix Schumacher
<[email protected]> 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?
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
