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. Will also need to be aware that BeanShell init could appear in two places with different property names and files. > 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
