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 < [email protected]> 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 <[email protected]> wrote: > >> On 9 September 2018 at 16:16, Felix Schumacher >> <[email protected]> wrote: >> > >> > >> > 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? >> >> 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>
