Hi, It's true users who D RTFM are confused by this concept. I intended to name it SharedVariables, do you think it's not clear enough ?
>From users perspective: - It would be available in JSR223 Test Elements as sharedVariables and be manipulated with simplified similar API as JMeterVariables (putObject, getObject,removeObject) Regards On Tue, Oct 24, 2017 at 10:27 AM, Andrey Pokhilko <[email protected]> wrote: > Would not it be confusing? We have variables and properties which > already confuse users. Now we introduce something third. How would it > look from user's perspective? > > Andrey Pokhilko > > 24.10.2017 11:09, Antonio Gomes Rodrigues пишет: > > +1 > > > > Antonio > > > > 2017-10-24 9:55 GMT+02:00 Maxime Chassagneux <[email protected]>: > > > >> Hi Philippe, > >> > >> Nice idea, look good for me. > >> > >> +1. > >> > >> > >> > >> 2017-10-24 9:36 GMT+02:00 Philippe Mouawad < > [email protected] > >>> : > >>> Hello, > >>> There is frequently the need in Load Testing for sharing something > >> accross > >>> threads which might have been initialized in a setup Thread Group or by > >>> some Thread. > >>> > >>> Currently JMeter has 2 ways to do it: > >>> > >>> - Properties but they are limited to String > >>> - Through Beanshell (which is deprecated) through bsh.shared > >>> > >>> > >>> A recent illustration of this (but I frequently in my work need it) is > >> the > >>> Coverage Tests created for JMS, TCP and FTP. > >>> To do it I had to use Beanshell. > >>> > >>> So I propose to create such concept: > >>> > >>> - JMeterContext would be enhanced with getSharedVariables() > >>> - A new equivalent of JMeterVariables would be created. The Map > would > >> be > >>> ConcurrentHashMap > >>> - It would be initialized/cleared in StandardJMeterEngine#run or > >>> JMeterContextService.startTest(); > >>> > >>> Thoughts ? > >>> -- > >>> Regards. > >>> Philippe Mouawad. > >>> Ubik-Ingénierie > >>> > > -- Cordialement. Philippe Mouawad.
