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 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
