You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Felix Schumacher <fe...@internetallee.de> on 2018/09/09 13:19:19 UTC
Re: svn commit: r1840406 - in /jmeter/trunk: bin/jmeter.properties
src/core/org/apache/jmeter/JMeter.java xdocs/changes.xml
xdocs/usermanual/properties_reference.xml
While I like groovy, it might be that other users have other JSR223
languages as their favourites.
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?
Felix
Am 09.09.2018 um 15:09 schrieb pmouawad@apache.org:
> Author: pmouawad
> Date: Sun Sep 9 13:09:21 2018
> New Revision: 1840406
>
> URL: http://svn.apache.org/viewvc?rev=1840406&view=rev
> Log:
> Bug 62700 - Introduce groovy.init.file to allow calling a groovy script on JMeter startup
> Bugzilla Id: 62700
>
> Modified:
> jmeter/trunk/bin/jmeter.properties
> jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
> jmeter/trunk/xdocs/changes.xml
> jmeter/trunk/xdocs/usermanual/properties_reference.xml
>
> Modified: jmeter/trunk/bin/jmeter.properties
> URL: http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.properties?rev=1840406&r1=1840405&r2=1840406&view=diff
> ==============================================================================
> --- jmeter/trunk/bin/jmeter.properties (original)
> +++ jmeter/trunk/bin/jmeter.properties Sun Sep 9 13:09:21 2018
> @@ -919,6 +919,13 @@ beanshell.server.file=../extras/startup.
> # Groovy function
> #---------------------------------------------------------------------------
>
> +# Path to Groovy file containing script to call on JMeter startup
> +# This script can use pre-defined variables:
> +# log : Logger to log any message
> +# props : JMeter Property
> +# OUT : System.OUT
> +#groovy.init.file=
> +
> #Path to Groovy file containing utility functions to make available to __groovy function
> #groovy.utilities=
>
>
> Modified: jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
> URL: http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/jmeter/JMeter.java?rev=1840406&r1=1840405&r2=1840406&view=diff
> ==============================================================================
> --- jmeter/trunk/src/core/org/apache/jmeter/JMeter.java (original)
> +++ jmeter/trunk/src/core/org/apache/jmeter/JMeter.java Sun Sep 9 13:09:21 2018
> @@ -22,6 +22,7 @@ import java.awt.event.ActionEvent;
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.FileNotFoundException;
> +import java.io.FileReader;
> import java.io.IOException;
> import java.io.InputStream;
> import java.net.Authenticator;
> @@ -44,6 +45,10 @@ import java.util.StringTokenizer;
> import java.util.concurrent.TimeUnit;
> import java.util.concurrent.atomic.AtomicInteger;
>
> +import javax.script.Bindings;
> +import javax.script.ScriptEngine;
> +import javax.script.ScriptEngineManager;
> +import javax.script.ScriptException;
> import javax.swing.JTree;
> import javax.swing.UIManager;
> import javax.swing.tree.TreePath;
> @@ -634,23 +639,7 @@ public class JMeter implements JMeterPlu
> t.run(); // NOSONAR we just evaluate some code here
> }
>
> - // Should we run a beanshell script on startup?
> - String bshinit = JMeterUtils.getProperty("beanshell.init.file");// $NON-NLS-1$
> - if (bshinit != null){
> - log.info("Run Beanshell on file: {}", bshinit);
> - try {
> - BeanShellInterpreter bsi = new BeanShellInterpreter();
> - bsi.source(bshinit);
> - } catch (ClassNotFoundException e) {
> - if (log.isWarnEnabled()) {
> - log.warn("Could not start Beanshell: {}", e.getLocalizedMessage());
> - }
> - } catch (JMeterException e) {
> - if (log.isWarnEnabled()) {
> - log.warn("Could not process Beanshell file: {}", e.getLocalizedMessage());
> - }
> - }
> - }
> + runInitScripts();
>
> int mirrorPort=JMeterUtils.getPropDefault("mirror.server.port", 0);// $NON-NLS-1$
> if (mirrorPort > 0){
> @@ -665,6 +654,51 @@ public class JMeter implements JMeterPlu
> }
> }
> }
> +
> +
> + /**
> + * Runs user configured init scripts
> + */
> + void runInitScripts() {
> + // Should we run a beanshell script on startup?
> + String bshinit = JMeterUtils.getProperty("beanshell.init.file");// $NON-NLS-1$
> + if (bshinit != null){
> + log.info("Running Beanshell on file: {}", bshinit);
> + try {
> + BeanShellInterpreter bsi = new BeanShellInterpreter();
> + bsi.source(bshinit);
> + } catch (ClassNotFoundException|JMeterException e) {
> + if (log.isWarnEnabled()) {
> + log.warn("Could not process Beanshell file: {}", e.getMessage());
> + }
> + }
> + }
> +
> + // Should we run a Groovy script on startup?
> + String jsr223Init = JMeterUtils.getProperty("groovy.init.file");// $NON-NLS-1$
> + if (jsr223Init != null){
> + log.info("Running Groovy init script in file: {}", jsr223Init);
> + File file = new File(jsr223Init);
> + if(file.exists() && file.canRead()) {
> + try (FileReader reader = new FileReader(file)) {
> + ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
> + ScriptEngine engine = scriptEngineManager.getEngineByName("Groovy");
> + Bindings bindings = engine.createBindings();
> + final Logger logger = LoggerFactory.getLogger("groovy.init.file");
> + bindings.put("log", logger); // $NON-NLS-1$ (this name is fixed)
> + Properties props = JMeterUtils.getJMeterProperties();
> + bindings.put("props", props); // $NON-NLS-1$ (this name is fixed)
> + // For use in debugging:
> + bindings.put("OUT", System.out); // NOSONAR $NON-NLS-1$ (this name is fixed)
> + engine.eval(reader, bindings);
> + } catch (IOException | ScriptException ex) {
> + log.error("Error running init script referenced by property {}", jsr223Init, ex);
> + }
> + } else {
> + log.error("Script {}Â referenced by property {}Â is not readable or does not exists", file.getAbsolutePath(), jsr223Init);
> + }
> + }
> + }
>
> /**
> * Sets a proxy server for the JVM if the command line arguments are
>
> Modified: jmeter/trunk/xdocs/changes.xml
> URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes.xml?rev=1840406&r1=1840405&r2=1840406&view=diff
> ==============================================================================
> --- jmeter/trunk/xdocs/changes.xml [utf-8] (original)
> +++ jmeter/trunk/xdocs/changes.xml [utf-8] Sun Sep 9 13:09:21 2018
> @@ -160,6 +160,7 @@ this behaviour, set <code>httpclient.res
> <li><bug>62470</bug>CSV Output : Enable logging of sub results when <code>jmeter.save.saveservice.subresults=true</code>. Contributed by Ubik Load Pack (support at ubikloadpack.com)</li>
> <li><bug>62473</bug>Setting "<code>saveservice_properties</code>" has counter intuitive behaviour</li>
> <li><bug>62354</bug>Correct calculation and usage of units for second per user (reported by jffagot05 at gmail.com)</li>
> + <li><bug>62700</bug>Introduce groovy.init.file to allow calling a groovy script on JMeter startup</li>
> <li><bug>62128</bug>Try to guess <code>JMETER_HOME</code> correctly, when <code>jmeter.bat</code> is called from a batch file in another directory. Contributed by logox01 (logox01 at gmx.at)</li>
> <li><pr>386</pr>Add parameter support for RMI keystore creation scripts. Contributed by Logan Mauzaize (t524467 at airfrance.fr)</li>
> <li><bug>62065</bug>Use Maven artifact for JAF Module instead of embedded module</li>
>
> Modified: jmeter/trunk/xdocs/usermanual/properties_reference.xml
> URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/properties_reference.xml?rev=1840406&r1=1840405&r2=1840406&view=diff
> ==============================================================================
> --- jmeter/trunk/xdocs/usermanual/properties_reference.xml (original)
> +++ jmeter/trunk/xdocs/usermanual/properties_reference.xml Sun Sep 9 13:09:21 2018
> @@ -1873,6 +1873,26 @@ JMETER-SERVER</source>
> </property>
> </properties>
> </section>
> +
> +<section name="§-num;.43 Advanced Groovy Scripting configuration" anchor="groovy">
> +<description>Advanced properties for configuration of scripting in Grooyv</description>
> +<properties>
> + <property name="groovy.init.file">
> + Path to Groovy file containing script to call on JMeter startup. <br/>
> + This script can use pre-defined variables:
> + <ul>
> + <li><code>log</code>: Logger to log any message, uses SLF4J library</li>
> + <li><code>props</code>: JMeter Properties</li>
> + <li><code>OUT</code>: System.OUT, useful to write in the console</li>
> + </ul>
> + No script is defined by default.
> + </property>
> + <property name="groovy.utilities">
> + Path to Groovy file containing utility functions to make available to __groovy function. <br/>
> + Defaults to <code>bin/utility.groovy</code>
> + </property>
> +</properties>
> +</section>
> <!--
> <section name="§-num;.10 Reports" anchor="Reports">
> <description>
>
>
Re: svn commit: r1840406 - in /jmeter/trunk: bin/jmeter.properties
src/core/org/apache/jmeter/JMeter.java xdocs/changes.xml
xdocs/usermanual/properties_reference.xml
Posted by Felix Schumacher <fe...@internetallee.de>.
Am Sonntag, den 09.09.2018, 16:18 +0200 schrieb Philippe Mouawad:
> On Sun, Sep 9, 2018 at 4:00 PM Felix Schumacher <
> felix.schumacher@internetallee.de> wrote:
>
> > Am Sonntag, den 09.09.2018, 15:51 +0200 schrieb Philippe Mouawad:
> > > Hello Felix, Sebb,
> > >
> > > The idea for my commit, was that:
> > > - It was proposed by a user
> > > - I personally had to use it on a project, and it was weird to
> > > see I
> > > had to
> > > use Beanshell to do that
> > > - Since we advise to replace Beanshell by Groovy, we should have
> > > all
> > > existing Beanshell features available as Groovy
> >
> > +1
> >
> > >
> > > Now regarding your remarks, I agree with you Felix that it would
> > > be
> > > nice.
> > > But no firm position for me but:
> > > - The risk I see with extension is that if file is misnamed ,
> > > what
> > > shall we
> > > do ?
> >
> > Present a nice message explaining that no scripting engine could be
> > found by that name.
> >
> > > - Sometimes we tend to be too open , making the software very
> > > customizable
> > > , but more complex. This tend to complexify Learning curve and I
> > > have
> > > seen
> > > this while giving trainings
> >
> > That is definitely a point, but on the other hand side you force
> > the
> > user to learn groovy, while she wants to use jython or something
> > different.
> >
> > > - IMO, since we advise using Groovy for scripting, it would be
> > > logical that
> > > we use it as a default. And since Javascript has bad
> > > performances, we
> > > should avoid users using it, as such not provide opportunity to
> > > use
> > > it
> > > (never, ever :-) )
> >
> > The bad performance of JavaScript is only true, if it is in highly
> > concurrent situation (or gets really worse when going into
> > concurrent
> > situations).
>
>
> Yes. I have seen it introduce contention once you reach > 100
> threads.
> That's why I think we have this bad reputation of not being able to
> scale
> above 300 threads.
> With groovy and probably Kotlin, no problem due to this thanks to
> Compilable scripts.
JavaScript (nashorn) is a compilable script, but it has problems on
initializing the context in concurrent situations.
>
>
> > That is probably not true for startup and I don't believe
> > that init scripts will be big, but then, I have never used one.
> >
>
> I agree on init script, it would not affect performance, my idea is
> just to
> say to user:
> - If you want to script in JMeter, use Groovy
That is good as long as the scripting engine gets love from its
developers. JMeter has seen more than one script language rise and
fall.
>
>
> > >
> > > But since I have no objection and might be wrong with my ideas,
> > > we
> > > can
> > > introduce another property (but it would be one more among tens).
> > > Note that Milamber was ready to start a release this sunday, so I
> > > don't
> > > know if you are ready to provide a commit for it before he builds
> > > the
> > > release
> >
> > If the release is planned for today, is it advisable to add a
> > feature
> > in the last moment? Those tend to make trouble.
> >
> >
>
> Yes, I agree.
> In this particular situation, I have been using this code since many
> weeks
> but lacked of time to document and commit it.
> I retested it after commit and saw no issue, that's why I committed.
> If you'd like to commit your patch, I can double test to avoid any
> issue
It is not only the code, that can cause problems, but rather the
expectations of the users or other developers. Especially parameter
names should not be changed after a release. And as this discussion
shows there are a few different expectations on the naming and
functionality.
Regards,
Felix
>
>
>
>
> > Regards,
> > Felix
> >
> > >
> > > Regards
> > >
> > > On Sun, Sep 9, 2018 at 3:19 PM Felix Schumacher <
> > > felix.schumacher@internetallee.de> wrote:
> > >
> > > > While I like groovy, it might be that other users have other
> > > > JSR223
> > > > languages as their favourites.
> > > >
> > > > 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?
> > > >
> > > > Felix
> > > >
> > > >
> > > > Am 09.09.2018 um 15:09 schrieb pmouawad@apache.org:
> > > > > Author: pmouawad
> > > > > Date: Sun Sep 9 13:09:21 2018
> > > > > New Revision: 1840406
> > > > >
> > > > > URL: http://svn.apache.org/viewvc?rev=1840406&view=rev
> > > > > Log:
> > > > > Bug 62700 - Introduce groovy.init.file to allow calling a
> > > > > groovy
> > > > > script
> > > >
> > > > on JMeter startup
> > > > > Bugzilla Id: 62700
> > > > >
> > > > > Modified:
> > > > > jmeter/trunk/bin/jmeter.properties
> > > > > jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
> > > > > jmeter/trunk/xdocs/changes.xml
> > > > > jmeter/trunk/xdocs/usermanual/properties_reference.xml
> > > > >
> > > > > Modified: jmeter/trunk/bin/jmeter.properties
> > > > > URL:
> > > >
> > > > http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.properties
> > > > ?rev
> > > > =1840406&r1=1840405&r2=1840406&view=diff
> > > > >
> > > >
> > > > ===============================================================
> > > > ====
> > > > ===========
> > > > > --- jmeter/trunk/bin/jmeter.properties (original)
> > > > > +++ jmeter/trunk/bin/jmeter.properties Sun Sep 9 13:09:21
> > > > > 2018
> > > > > @@ -919,6 +919,13 @@ beanshell.server.file=../extras/startup.
> > > > > # Groovy function
> > > > >
> > > >
> > > > #-------------------------------------------------------------
> > > > ----
> > > > ----------
> > > > >
> > > > > +# Path to Groovy file containing script to call on JMeter
> > > > > startup
> > > > > +# This script can use pre-defined variables:
> > > > > +# log : Logger to log any message
> > > > > +# props : JMeter Property
> > > > > +# OUT : System.OUT
> > > > > +#groovy.init.file=
> > > > > +
> > > > > #Path to Groovy file containing utility functions to make
> > > > > available to
> > > >
> > > > __groovy function
> > > > > #groovy.utilities=
> > > > >
> > > > >
> > > > > Modified: jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
> > > > > URL:
> > > >
> > > > http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/j
> > > > mete
> > > > r/JMeter.java?rev=1840406&r1=1840405&r2=1840406&view=diff
> > > > >
> > > >
> > > > ===============================================================
> > > > ====
> > > > ===========
> > > > > --- jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
> > > > > (original)
> > > > > +++ jmeter/trunk/src/core/org/apache/jmeter/JMeter.java Sun
> > > > > Sep 9
> > > >
> > > > 13:09:21 2018
> > > > > @@ -22,6 +22,7 @@ import java.awt.event.ActionEvent;
> > > > > import java.io.File;
> > > > > import java.io.FileInputStream;
> > > > > import java.io.FileNotFoundException;
> > > > > +import java.io.FileReader;
> > > > > import java.io.IOException;
> > > > > import java.io.InputStream;
> > > > > import java.net.Authenticator;
> > > > > @@ -44,6 +45,10 @@ import java.util.StringTokenizer;
> > > > > import java.util.concurrent.TimeUnit;
> > > > > import java.util.concurrent.atomic.AtomicInteger;
> > > > >
> > > > > +import javax.script.Bindings;
> > > > > +import javax.script.ScriptEngine;
> > > > > +import javax.script.ScriptEngineManager;
> > > > > +import javax.script.ScriptException;
> > > > > import javax.swing.JTree;
> > > > > import javax.swing.UIManager;
> > > > > import javax.swing.tree.TreePath;
> > > > > @@ -634,23 +639,7 @@ public class JMeter implements JMeterPlu
> > > > > t.run(); // NOSONAR we just evaluate some code
> > > > > here
> > > > > }
> > > > >
> > > > > - // Should we run a beanshell script on startup?
> > > > > - String bshinit =
> > > >
> > > > JMeterUtils.getProperty("beanshell.init.file");// $NON-NLS-1$
> > > > > - if (bshinit != null){
> > > > > - log.info("Run Beanshell on file: {}", bshinit);
> > > > > - try {
> > > > > - BeanShellInterpreter bsi = new
> > > > > BeanShellInterpreter();
> > > > > - bsi.source(bshinit);
> > > > > - } catch (ClassNotFoundException e) {
> > > > > - if (log.isWarnEnabled()) {
> > > > > - log.warn("Could not start Beanshell:
> > > > > {}",
> > > >
> > > > e.getLocalizedMessage());
> > > > > - }
> > > > > - } catch (JMeterException e) {
> > > > > - if (log.isWarnEnabled()) {
> > > > > - log.warn("Could not process Beanshell
> > > > > file:
> > > > > {}",
> > > >
> > > > e.getLocalizedMessage());
> > > > > - }
> > > > > - }
> > > > > - }
> > > > > + runInitScripts();
> > > > >
> > > > > int
> > > >
> > > > mirrorPort=JMeterUtils.getPropDefault("mirror.server.port",
> > > > 0);//
> > > > $NON-NLS-1$
> > > > > if (mirrorPort > 0){
> > > > > @@ -665,6 +654,51 @@ public class JMeter implements JMeterPlu
> > > > > }
> > > > > }
> > > > > }
> > > > > +
> > > > > +
> > > > > + /**
> > > > > + * Runs user configured init scripts
> > > > > + */
> > > > > + void runInitScripts() {
> > > > > + // Should we run a beanshell script on startup?
> > > > > + String bshinit =
> > > >
> > > > JMeterUtils.getProperty("beanshell.init.file");// $NON-NLS-1$
> > > > > + if (bshinit != null){
> > > > > + log.info("Running Beanshell on file: {}",
> > > > > bshinit);
> > > > > + try {
> > > > > + BeanShellInterpreter bsi = new
> > > > > BeanShellInterpreter();
> > > > > + bsi.source(bshinit);
> > > > > + } catch (ClassNotFoundException|JMeterException
> > > > > e) {
> > > > > + if (log.isWarnEnabled()) {
> > > > > + log.warn("Could not process Beanshell
> > > > > file:
> > > > > {}",
> > > >
> > > > e.getMessage());
> > > > > + }
> > > > > + }
> > > > > + }
> > > > > +
> > > > > + // Should we run a Groovy script on startup?
> > > > > + String jsr223Init =
> > > >
> > > > JMeterUtils.getProperty("groovy.init.file");// $NON-NLS-1$
> > > > > + if (jsr223Init != null){
> > > > > + log.info("Running Groovy init script in file:
> > > > > {}",
> > > >
> > > > jsr223Init);
> > > > > + File file = new File(jsr223Init);
> > > > > + if(file.exists() && file.canRead()) {
> > > > > + try (FileReader reader = new
> > > > > FileReader(file)) {
> > > > > + ScriptEngineManager scriptEngineManager
> > > > > =
> > > > > new
> > > >
> > > > ScriptEngineManager();
> > > > > + ScriptEngine engine =
> > > >
> > > > scriptEngineManager.getEngineByName("Groovy");
> > > > > + Bindings bindings =
> > > > > engine.createBindings();
> > > > > + final Logger logger =
> > > >
> > > > LoggerFactory.getLogger("groovy.init.file");
> > > > > + bindings.put("log", logger); // $NON-
> > > > > NLS-1$
> > > > > (this
> > > >
> > > > name is fixed)
> > > > > + Properties props =
> > > >
> > > > JMeterUtils.getJMeterProperties();
> > > > > + bindings.put("props", props); // $NON-
> > > > > NLS-1$
> > > > > (this
> > > >
> > > > name is fixed)
> > > > > + // For use in debugging:
> > > > > + bindings.put("OUT", System.out); //
> > > > > NOSONAR
> > > >
> > > > $NON-NLS-1$ (this name is fixed)
> > > > > + engine.eval(reader, bindings);
> > > > > + } catch (IOException | ScriptException ex) {
> > > > > + log.error("Error running init script
> > > > > referenced by
> > > >
> > > > property {}", jsr223Init, ex);
> > > > > + }
> > > > > + } else {
> > > > > + log.error("Script {}Â referenced by property
> > > > > {}Â
> > > > > is not
> > > >
> > > > readable or does not exists", file.getAbsolutePath(),
> > > > jsr223Init);
> > > > > + }
> > > > > + }
> > > > > + }
> > > > >
> > > > > /**
> > > > > * Sets a proxy server for the JVM if the command line
> > > > > arguments
> > > >
> > > > are
> > > > >
> > > > > Modified: jmeter/trunk/xdocs/changes.xml
> > > > > URL:
> > > >
> > > > http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes.xml?rev
> > > > =184
> > > > 0406&r1=1840405&r2=1840406&view=diff
> > > > >
> > > >
> > > > ===============================================================
> > > > ====
> > > > ===========
> > > > > --- jmeter/trunk/xdocs/changes.xml [utf-8] (original)
> > > > > +++ jmeter/trunk/xdocs/changes.xml [utf-8] Sun Sep 9
> > > > > 13:09:21
> > > > > 2018
> > > > > @@ -160,6 +160,7 @@ this behaviour, set <code>httpclient.res
> > > > > <li><bug>62470</bug>CSV Output : Enable logging of sub
> > > > > results when
> > > >
> > > > <code>jmeter.save.saveservice.subresults=true</code>.
> > > > Contributed
> > > > by Ubik
> > > > Load Pack (support at ubikloadpack.com)</li>
> > > > > <li><bug>62473</bug>Setting
> > > > > "<code>saveservice_properties</code>"
> > > >
> > > > has counter intuitive behaviour</li>
> > > > > <li><bug>62354</bug>Correct calculation and usage of
> > > > > units
> > > > > for
> > > >
> > > > second per user (reported by jffagot05 at gmail.com)</li>
> > > > > + <li><bug>62700</bug>Introduce groovy.init.file to allow
> > > > > calling a
> > > >
> > > > groovy script on JMeter startup</li>
> > > > > <li><bug>62128</bug>Try to guess <code>JMETER_HOME</code>
> > > > > correctly,
> > > >
> > > > when <code>jmeter.bat</code> is called from a batch file in
> > > > another
> > > > directory. Contributed by logox01 (logox01 at gmx.at)</li>
> > > > > <li><pr>386</pr>Add parameter support for RMI keystore
> > > > > creation
> > > >
> > > > scripts. Contributed by Logan Mauzaize (t524467 at
> > > > airfrance.fr)</li>
> > > > > <li><bug>62065</bug>Use Maven artifact for JAF Module
> > > > > instead
> > > > > of
> > > >
> > > > embedded module</li>
> > > > >
> > > > > Modified:
> > > > > jmeter/trunk/xdocs/usermanual/properties_reference.xml
> > > > > URL:
> > > >
> > > > http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/prop
> > > > erti
> > > > es_reference.xml?rev=1840406&r1=1840405&r2=1840406&view=diff
> > > > >
> > > >
> > > > ===============================================================
> > > > ====
> > > > ===========
> > > > > --- jmeter/trunk/xdocs/usermanual/properties_reference.xml
> > > > > (original)
> > > > > +++ jmeter/trunk/xdocs/usermanual/properties_reference.xml
> > > > > Sun
> > > > > Sep 9
> > > >
> > > > 13:09:21 2018
> > > > > @@ -1873,6 +1873,26 @@ JMETER-SERVER</source>
> > > > > </property>
> > > > > </properties>
> > > > > </section>
> > > > > +
> > > > > +<section name="§-num;.43 Advanced Groovy Scripting
> > > > > configuration"
> > > >
> > > > anchor="groovy">
> > > > > +<description>Advanced properties for configuration of
> > > > > scripting
> > > > > in
> > > >
> > > > Grooyv</description>
> > > > > +<properties>
> > > > > + <property name="groovy.init.file">
> > > > > + Path to Groovy file containing script to call on JMeter
> > > > > startup.
> > > >
> > > > <br/>
> > > > > + This script can use pre-defined variables:
> > > > > + <ul>
> > > > > + <li><code>log</code>: Logger to log any message,
> > > > > uses
> > > > > SLF4J
> > > >
> > > > library</li>
> > > > > + <li><code>props</code>: JMeter Properties</li>
> > > > > + <li><code>OUT</code>: System.OUT, useful to write in
> > > > > the
> > > >
> > > > console</li>
> > > > > + </ul>
> > > > > + No script is defined by default.
> > > > > + </property>
> > > > > + <property name="groovy.utilities">
> > > > > + Path to Groovy file containing utility functions to make
> > > > > available
> > > >
> > > > to __groovy function. <br/>
> > > > > + Defaults to <code>bin/utility.groovy</code>
> > > > > + </property>
> > > > > +</properties>
> > > > > +</section>
> > > > > <!--
> > > > > <section name="§-num;.10 Reports" anchor="Reports">
> > > > > <description>
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>
>
Re: svn commit: r1840406 - in /jmeter/trunk: bin/jmeter.properties
src/core/org/apache/jmeter/JMeter.java xdocs/changes.xml xdocs/usermanual/properties_reference.xml
Posted by Philippe Mouawad <ph...@gmail.com>.
On Sun, Sep 9, 2018 at 4:00 PM Felix Schumacher <
felix.schumacher@internetallee.de> wrote:
> Am Sonntag, den 09.09.2018, 15:51 +0200 schrieb Philippe Mouawad:
> > Hello Felix, Sebb,
> >
> > The idea for my commit, was that:
> > - It was proposed by a user
> > - I personally had to use it on a project, and it was weird to see I
> > had to
> > use Beanshell to do that
> > - Since we advise to replace Beanshell by Groovy, we should have all
> > existing Beanshell features available as Groovy
>
> +1
>
> >
> > Now regarding your remarks, I agree with you Felix that it would be
> > nice.
> > But no firm position for me but:
> > - The risk I see with extension is that if file is misnamed , what
> > shall we
> > do ?
>
> Present a nice message explaining that no scripting engine could be
> found by that name.
>
> > - Sometimes we tend to be too open , making the software very
> > customizable
> > , but more complex. This tend to complexify Learning curve and I have
> > seen
> > this while giving trainings
>
> That is definitely a point, but on the other hand side you force the
> user to learn groovy, while she wants to use jython or something
> different.
>
> > - IMO, since we advise using Groovy for scripting, it would be
> > logical that
> > we use it as a default. And since Javascript has bad performances, we
> > should avoid users using it, as such not provide opportunity to use
> > it
> > (never, ever :-) )
>
> The bad performance of JavaScript is only true, if it is in highly
> concurrent situation (or gets really worse when going into concurrent
> situations).
Yes. I have seen it introduce contention once you reach > 100 threads.
That's why I think we have this bad reputation of not being able to scale
above 300 threads.
With groovy and probably Kotlin, no problem due to this thanks to
Compilable scripts.
> That is probably not true for startup and I don't believe
> that init scripts will be big, but then, I have never used one.
>
I agree on init script, it would not affect performance, my idea is just to
say to user:
- If you want to script in JMeter, use Groovy
> >
> > But since I have no objection and might be wrong with my ideas, we
> > can
> > introduce another property (but it would be one more among tens).
> > Note that Milamber was ready to start a release this sunday, so I
> > don't
> > know if you are ready to provide a commit for it before he builds the
> > release
>
> If the release is planned for today, is it advisable to add a feature
> in the last moment? Those tend to make trouble.
>
>
Yes, I agree.
In this particular situation, I have been using this code since many weeks
but lacked of time to document and commit it.
I retested it after commit and saw no issue, that's why I committed.
If you'd like to commit your patch, I can double test to avoid any issue
> Regards,
> Felix
>
> >
> > Regards
> >
> > On Sun, Sep 9, 2018 at 3:19 PM Felix Schumacher <
> > felix.schumacher@internetallee.de> wrote:
> >
> > > While I like groovy, it might be that other users have other JSR223
> > > languages as their favourites.
> > >
> > > 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?
> > >
> > > Felix
> > >
> > >
> > > Am 09.09.2018 um 15:09 schrieb pmouawad@apache.org:
> > > > Author: pmouawad
> > > > Date: Sun Sep 9 13:09:21 2018
> > > > New Revision: 1840406
> > > >
> > > > URL: http://svn.apache.org/viewvc?rev=1840406&view=rev
> > > > Log:
> > > > Bug 62700 - Introduce groovy.init.file to allow calling a groovy
> > > > script
> > >
> > > on JMeter startup
> > > > Bugzilla Id: 62700
> > > >
> > > > Modified:
> > > > jmeter/trunk/bin/jmeter.properties
> > > > jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
> > > > jmeter/trunk/xdocs/changes.xml
> > > > jmeter/trunk/xdocs/usermanual/properties_reference.xml
> > > >
> > > > Modified: jmeter/trunk/bin/jmeter.properties
> > > > URL:
> > >
> > > http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.properties?rev
> > > =1840406&r1=1840405&r2=1840406&view=diff
> > > >
> > >
> > > ===================================================================
> > > ===========
> > > > --- jmeter/trunk/bin/jmeter.properties (original)
> > > > +++ jmeter/trunk/bin/jmeter.properties Sun Sep 9 13:09:21 2018
> > > > @@ -919,6 +919,13 @@ beanshell.server.file=../extras/startup.
> > > > # Groovy function
> > > >
> > >
> > > #-----------------------------------------------------------------
> > > ----------
> > > >
> > > > +# Path to Groovy file containing script to call on JMeter
> > > > startup
> > > > +# This script can use pre-defined variables:
> > > > +# log : Logger to log any message
> > > > +# props : JMeter Property
> > > > +# OUT : System.OUT
> > > > +#groovy.init.file=
> > > > +
> > > > #Path to Groovy file containing utility functions to make
> > > > available to
> > >
> > > __groovy function
> > > > #groovy.utilities=
> > > >
> > > >
> > > > Modified: jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
> > > > URL:
> > >
> > > http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/jmete
> > > r/JMeter.java?rev=1840406&r1=1840405&r2=1840406&view=diff
> > > >
> > >
> > > ===================================================================
> > > ===========
> > > > --- jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
> > > > (original)
> > > > +++ jmeter/trunk/src/core/org/apache/jmeter/JMeter.java Sun
> > > > Sep 9
> > >
> > > 13:09:21 2018
> > > > @@ -22,6 +22,7 @@ import java.awt.event.ActionEvent;
> > > > import java.io.File;
> > > > import java.io.FileInputStream;
> > > > import java.io.FileNotFoundException;
> > > > +import java.io.FileReader;
> > > > import java.io.IOException;
> > > > import java.io.InputStream;
> > > > import java.net.Authenticator;
> > > > @@ -44,6 +45,10 @@ import java.util.StringTokenizer;
> > > > import java.util.concurrent.TimeUnit;
> > > > import java.util.concurrent.atomic.AtomicInteger;
> > > >
> > > > +import javax.script.Bindings;
> > > > +import javax.script.ScriptEngine;
> > > > +import javax.script.ScriptEngineManager;
> > > > +import javax.script.ScriptException;
> > > > import javax.swing.JTree;
> > > > import javax.swing.UIManager;
> > > > import javax.swing.tree.TreePath;
> > > > @@ -634,23 +639,7 @@ public class JMeter implements JMeterPlu
> > > > t.run(); // NOSONAR we just evaluate some code here
> > > > }
> > > >
> > > > - // Should we run a beanshell script on startup?
> > > > - String bshinit =
> > >
> > > JMeterUtils.getProperty("beanshell.init.file");// $NON-NLS-1$
> > > > - if (bshinit != null){
> > > > - log.info("Run Beanshell on file: {}", bshinit);
> > > > - try {
> > > > - BeanShellInterpreter bsi = new
> > > > BeanShellInterpreter();
> > > > - bsi.source(bshinit);
> > > > - } catch (ClassNotFoundException e) {
> > > > - if (log.isWarnEnabled()) {
> > > > - log.warn("Could not start Beanshell: {}",
> > >
> > > e.getLocalizedMessage());
> > > > - }
> > > > - } catch (JMeterException e) {
> > > > - if (log.isWarnEnabled()) {
> > > > - log.warn("Could not process Beanshell file:
> > > > {}",
> > >
> > > e.getLocalizedMessage());
> > > > - }
> > > > - }
> > > > - }
> > > > + runInitScripts();
> > > >
> > > > int
> > >
> > > mirrorPort=JMeterUtils.getPropDefault("mirror.server.port", 0);//
> > > $NON-NLS-1$
> > > > if (mirrorPort > 0){
> > > > @@ -665,6 +654,51 @@ public class JMeter implements JMeterPlu
> > > > }
> > > > }
> > > > }
> > > > +
> > > > +
> > > > + /**
> > > > + * Runs user configured init scripts
> > > > + */
> > > > + void runInitScripts() {
> > > > + // Should we run a beanshell script on startup?
> > > > + String bshinit =
> > >
> > > JMeterUtils.getProperty("beanshell.init.file");// $NON-NLS-1$
> > > > + if (bshinit != null){
> > > > + log.info("Running Beanshell on file: {}", bshinit);
> > > > + try {
> > > > + BeanShellInterpreter bsi = new
> > > > BeanShellInterpreter();
> > > > + bsi.source(bshinit);
> > > > + } catch (ClassNotFoundException|JMeterException e) {
> > > > + if (log.isWarnEnabled()) {
> > > > + log.warn("Could not process Beanshell file:
> > > > {}",
> > >
> > > e.getMessage());
> > > > + }
> > > > + }
> > > > + }
> > > > +
> > > > + // Should we run a Groovy script on startup?
> > > > + String jsr223Init =
> > >
> > > JMeterUtils.getProperty("groovy.init.file");// $NON-NLS-1$
> > > > + if (jsr223Init != null){
> > > > + log.info("Running Groovy init script in file: {}",
> > >
> > > jsr223Init);
> > > > + File file = new File(jsr223Init);
> > > > + if(file.exists() && file.canRead()) {
> > > > + try (FileReader reader = new FileReader(file)) {
> > > > + ScriptEngineManager scriptEngineManager =
> > > > new
> > >
> > > ScriptEngineManager();
> > > > + ScriptEngine engine =
> > >
> > > scriptEngineManager.getEngineByName("Groovy");
> > > > + Bindings bindings = engine.createBindings();
> > > > + final Logger logger =
> > >
> > > LoggerFactory.getLogger("groovy.init.file");
> > > > + bindings.put("log", logger); // $NON-NLS-1$
> > > > (this
> > >
> > > name is fixed)
> > > > + Properties props =
> > >
> > > JMeterUtils.getJMeterProperties();
> > > > + bindings.put("props", props); // $NON-NLS-1$
> > > > (this
> > >
> > > name is fixed)
> > > > + // For use in debugging:
> > > > + bindings.put("OUT", System.out); // NOSONAR
> > >
> > > $NON-NLS-1$ (this name is fixed)
> > > > + engine.eval(reader, bindings);
> > > > + } catch (IOException | ScriptException ex) {
> > > > + log.error("Error running init script
> > > > referenced by
> > >
> > > property {}", jsr223Init, ex);
> > > > + }
> > > > + } else {
> > > > + log.error("Script {}Â referenced by property {}Â
> > > > is not
> > >
> > > readable or does not exists", file.getAbsolutePath(), jsr223Init);
> > > > + }
> > > > + }
> > > > + }
> > > >
> > > > /**
> > > > * Sets a proxy server for the JVM if the command line
> > > > arguments
> > >
> > > are
> > > >
> > > > Modified: jmeter/trunk/xdocs/changes.xml
> > > > URL:
> > >
> > > http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes.xml?rev=184
> > > 0406&r1=1840405&r2=1840406&view=diff
> > > >
> > >
> > > ===================================================================
> > > ===========
> > > > --- jmeter/trunk/xdocs/changes.xml [utf-8] (original)
> > > > +++ jmeter/trunk/xdocs/changes.xml [utf-8] Sun Sep 9 13:09:21
> > > > 2018
> > > > @@ -160,6 +160,7 @@ this behaviour, set <code>httpclient.res
> > > > <li><bug>62470</bug>CSV Output : Enable logging of sub
> > > > results when
> > >
> > > <code>jmeter.save.saveservice.subresults=true</code>. Contributed
> > > by Ubik
> > > Load Pack (support at ubikloadpack.com)</li>
> > > > <li><bug>62473</bug>Setting
> > > > "<code>saveservice_properties</code>"
> > >
> > > has counter intuitive behaviour</li>
> > > > <li><bug>62354</bug>Correct calculation and usage of units
> > > > for
> > >
> > > second per user (reported by jffagot05 at gmail.com)</li>
> > > > + <li><bug>62700</bug>Introduce groovy.init.file to allow
> > > > calling a
> > >
> > > groovy script on JMeter startup</li>
> > > > <li><bug>62128</bug>Try to guess <code>JMETER_HOME</code>
> > > > correctly,
> > >
> > > when <code>jmeter.bat</code> is called from a batch file in another
> > > directory. Contributed by logox01 (logox01 at gmx.at)</li>
> > > > <li><pr>386</pr>Add parameter support for RMI keystore
> > > > creation
> > >
> > > scripts. Contributed by Logan Mauzaize (t524467 at
> > > airfrance.fr)</li>
> > > > <li><bug>62065</bug>Use Maven artifact for JAF Module instead
> > > > of
> > >
> > > embedded module</li>
> > > >
> > > > Modified: jmeter/trunk/xdocs/usermanual/properties_reference.xml
> > > > URL:
> > >
> > > http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/properti
> > > es_reference.xml?rev=1840406&r1=1840405&r2=1840406&view=diff
> > > >
> > >
> > > ===================================================================
> > > ===========
> > > > --- jmeter/trunk/xdocs/usermanual/properties_reference.xml
> > > > (original)
> > > > +++ jmeter/trunk/xdocs/usermanual/properties_reference.xml Sun
> > > > Sep 9
> > >
> > > 13:09:21 2018
> > > > @@ -1873,6 +1873,26 @@ JMETER-SERVER</source>
> > > > </property>
> > > > </properties>
> > > > </section>
> > > > +
> > > > +<section name="§-num;.43 Advanced Groovy Scripting
> > > > configuration"
> > >
> > > anchor="groovy">
> > > > +<description>Advanced properties for configuration of scripting
> > > > in
> > >
> > > Grooyv</description>
> > > > +<properties>
> > > > + <property name="groovy.init.file">
> > > > + Path to Groovy file containing script to call on JMeter
> > > > startup.
> > >
> > > <br/>
> > > > + This script can use pre-defined variables:
> > > > + <ul>
> > > > + <li><code>log</code>: Logger to log any message, uses
> > > > SLF4J
> > >
> > > library</li>
> > > > + <li><code>props</code>: JMeter Properties</li>
> > > > + <li><code>OUT</code>: System.OUT, useful to write in the
> > >
> > > console</li>
> > > > + </ul>
> > > > + No script is defined by default.
> > > > + </property>
> > > > + <property name="groovy.utilities">
> > > > + Path to Groovy file containing utility functions to make
> > > > available
> > >
> > > to __groovy function. <br/>
> > > > + Defaults to <code>bin/utility.groovy</code>
> > > > + </property>
> > > > +</properties>
> > > > +</section>
> > > > <!--
> > > > <section name="§-num;.10 Reports" anchor="Reports">
> > > > <description>
> > > >
> > > >
> > >
> > >
> >
> >
>
--
Cordialement.
Philippe Mouawad.
Re: svn commit: r1840406 - in /jmeter/trunk: bin/jmeter.properties
src/core/org/apache/jmeter/JMeter.java xdocs/changes.xml
xdocs/usermanual/properties_reference.xml
Posted by Felix Schumacher <fe...@internetallee.de>.
Am Sonntag, den 09.09.2018, 15:51 +0200 schrieb Philippe Mouawad:
> Hello Felix, Sebb,
>
> The idea for my commit, was that:
> - It was proposed by a user
> - I personally had to use it on a project, and it was weird to see I
> had to
> use Beanshell to do that
> - Since we advise to replace Beanshell by Groovy, we should have all
> existing Beanshell features available as Groovy
+1
>
> Now regarding your remarks, I agree with you Felix that it would be
> nice.
> But no firm position for me but:
> - The risk I see with extension is that if file is misnamed , what
> shall we
> do ?
Present a nice message explaining that no scripting engine could be
found by that name.
> - Sometimes we tend to be too open , making the software very
> customizable
> , but more complex. This tend to complexify Learning curve and I have
> seen
> this while giving trainings
That is definitely a point, but on the other hand side you force the
user to learn groovy, while she wants to use jython or something
different.
> - IMO, since we advise using Groovy for scripting, it would be
> logical that
> we use it as a default. And since Javascript has bad performances, we
> should avoid users using it, as such not provide opportunity to use
> it
> (never, ever :-) )
The bad performance of JavaScript is only true, if it is in highly
concurrent situation (or gets really worse when going into concurrent
situations). That is probably not true for startup and I don't believe
that init scripts will be big, but then, I have never used one.
>
> But since I have no objection and might be wrong with my ideas, we
> can
> introduce another property (but it would be one more among tens).
> Note that Milamber was ready to start a release this sunday, so I
> don't
> know if you are ready to provide a commit for it before he builds the
> release
If the release is planned for today, is it advisable to add a feature
in the last moment? Those tend to make trouble.
Regards,
Felix
>
> Regards
>
> On Sun, Sep 9, 2018 at 3:19 PM Felix Schumacher <
> felix.schumacher@internetallee.de> wrote:
>
> > While I like groovy, it might be that other users have other JSR223
> > languages as their favourites.
> >
> > 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?
> >
> > Felix
> >
> >
> > Am 09.09.2018 um 15:09 schrieb pmouawad@apache.org:
> > > Author: pmouawad
> > > Date: Sun Sep 9 13:09:21 2018
> > > New Revision: 1840406
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1840406&view=rev
> > > Log:
> > > Bug 62700 - Introduce groovy.init.file to allow calling a groovy
> > > script
> >
> > on JMeter startup
> > > Bugzilla Id: 62700
> > >
> > > Modified:
> > > jmeter/trunk/bin/jmeter.properties
> > > jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
> > > jmeter/trunk/xdocs/changes.xml
> > > jmeter/trunk/xdocs/usermanual/properties_reference.xml
> > >
> > > Modified: jmeter/trunk/bin/jmeter.properties
> > > URL:
> >
> > http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.properties?rev
> > =1840406&r1=1840405&r2=1840406&view=diff
> > >
> >
> > ===================================================================
> > ===========
> > > --- jmeter/trunk/bin/jmeter.properties (original)
> > > +++ jmeter/trunk/bin/jmeter.properties Sun Sep 9 13:09:21 2018
> > > @@ -919,6 +919,13 @@ beanshell.server.file=../extras/startup.
> > > # Groovy function
> > >
> >
> > #-----------------------------------------------------------------
> > ----------
> > >
> > > +# Path to Groovy file containing script to call on JMeter
> > > startup
> > > +# This script can use pre-defined variables:
> > > +# log : Logger to log any message
> > > +# props : JMeter Property
> > > +# OUT : System.OUT
> > > +#groovy.init.file=
> > > +
> > > #Path to Groovy file containing utility functions to make
> > > available to
> >
> > __groovy function
> > > #groovy.utilities=
> > >
> > >
> > > Modified: jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
> > > URL:
> >
> > http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/jmete
> > r/JMeter.java?rev=1840406&r1=1840405&r2=1840406&view=diff
> > >
> >
> > ===================================================================
> > ===========
> > > --- jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
> > > (original)
> > > +++ jmeter/trunk/src/core/org/apache/jmeter/JMeter.java Sun
> > > Sep 9
> >
> > 13:09:21 2018
> > > @@ -22,6 +22,7 @@ import java.awt.event.ActionEvent;
> > > import java.io.File;
> > > import java.io.FileInputStream;
> > > import java.io.FileNotFoundException;
> > > +import java.io.FileReader;
> > > import java.io.IOException;
> > > import java.io.InputStream;
> > > import java.net.Authenticator;
> > > @@ -44,6 +45,10 @@ import java.util.StringTokenizer;
> > > import java.util.concurrent.TimeUnit;
> > > import java.util.concurrent.atomic.AtomicInteger;
> > >
> > > +import javax.script.Bindings;
> > > +import javax.script.ScriptEngine;
> > > +import javax.script.ScriptEngineManager;
> > > +import javax.script.ScriptException;
> > > import javax.swing.JTree;
> > > import javax.swing.UIManager;
> > > import javax.swing.tree.TreePath;
> > > @@ -634,23 +639,7 @@ public class JMeter implements JMeterPlu
> > > t.run(); // NOSONAR we just evaluate some code here
> > > }
> > >
> > > - // Should we run a beanshell script on startup?
> > > - String bshinit =
> >
> > JMeterUtils.getProperty("beanshell.init.file");// $NON-NLS-1$
> > > - if (bshinit != null){
> > > - log.info("Run Beanshell on file: {}", bshinit);
> > > - try {
> > > - BeanShellInterpreter bsi = new
> > > BeanShellInterpreter();
> > > - bsi.source(bshinit);
> > > - } catch (ClassNotFoundException e) {
> > > - if (log.isWarnEnabled()) {
> > > - log.warn("Could not start Beanshell: {}",
> >
> > e.getLocalizedMessage());
> > > - }
> > > - } catch (JMeterException e) {
> > > - if (log.isWarnEnabled()) {
> > > - log.warn("Could not process Beanshell file:
> > > {}",
> >
> > e.getLocalizedMessage());
> > > - }
> > > - }
> > > - }
> > > + runInitScripts();
> > >
> > > int
> >
> > mirrorPort=JMeterUtils.getPropDefault("mirror.server.port", 0);//
> > $NON-NLS-1$
> > > if (mirrorPort > 0){
> > > @@ -665,6 +654,51 @@ public class JMeter implements JMeterPlu
> > > }
> > > }
> > > }
> > > +
> > > +
> > > + /**
> > > + * Runs user configured init scripts
> > > + */
> > > + void runInitScripts() {
> > > + // Should we run a beanshell script on startup?
> > > + String bshinit =
> >
> > JMeterUtils.getProperty("beanshell.init.file");// $NON-NLS-1$
> > > + if (bshinit != null){
> > > + log.info("Running Beanshell on file: {}", bshinit);
> > > + try {
> > > + BeanShellInterpreter bsi = new
> > > BeanShellInterpreter();
> > > + bsi.source(bshinit);
> > > + } catch (ClassNotFoundException|JMeterException e) {
> > > + if (log.isWarnEnabled()) {
> > > + log.warn("Could not process Beanshell file:
> > > {}",
> >
> > e.getMessage());
> > > + }
> > > + }
> > > + }
> > > +
> > > + // Should we run a Groovy script on startup?
> > > + String jsr223Init =
> >
> > JMeterUtils.getProperty("groovy.init.file");// $NON-NLS-1$
> > > + if (jsr223Init != null){
> > > + log.info("Running Groovy init script in file: {}",
> >
> > jsr223Init);
> > > + File file = new File(jsr223Init);
> > > + if(file.exists() && file.canRead()) {
> > > + try (FileReader reader = new FileReader(file)) {
> > > + ScriptEngineManager scriptEngineManager =
> > > new
> >
> > ScriptEngineManager();
> > > + ScriptEngine engine =
> >
> > scriptEngineManager.getEngineByName("Groovy");
> > > + Bindings bindings = engine.createBindings();
> > > + final Logger logger =
> >
> > LoggerFactory.getLogger("groovy.init.file");
> > > + bindings.put("log", logger); // $NON-NLS-1$
> > > (this
> >
> > name is fixed)
> > > + Properties props =
> >
> > JMeterUtils.getJMeterProperties();
> > > + bindings.put("props", props); // $NON-NLS-1$
> > > (this
> >
> > name is fixed)
> > > + // For use in debugging:
> > > + bindings.put("OUT", System.out); // NOSONAR
> >
> > $NON-NLS-1$ (this name is fixed)
> > > + engine.eval(reader, bindings);
> > > + } catch (IOException | ScriptException ex) {
> > > + log.error("Error running init script
> > > referenced by
> >
> > property {}", jsr223Init, ex);
> > > + }
> > > + } else {
> > > + log.error("Script {}Â referenced by property {}Â
> > > is not
> >
> > readable or does not exists", file.getAbsolutePath(), jsr223Init);
> > > + }
> > > + }
> > > + }
> > >
> > > /**
> > > * Sets a proxy server for the JVM if the command line
> > > arguments
> >
> > are
> > >
> > > Modified: jmeter/trunk/xdocs/changes.xml
> > > URL:
> >
> > http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes.xml?rev=184
> > 0406&r1=1840405&r2=1840406&view=diff
> > >
> >
> > ===================================================================
> > ===========
> > > --- jmeter/trunk/xdocs/changes.xml [utf-8] (original)
> > > +++ jmeter/trunk/xdocs/changes.xml [utf-8] Sun Sep 9 13:09:21
> > > 2018
> > > @@ -160,6 +160,7 @@ this behaviour, set <code>httpclient.res
> > > <li><bug>62470</bug>CSV Output : Enable logging of sub
> > > results when
> >
> > <code>jmeter.save.saveservice.subresults=true</code>. Contributed
> > by Ubik
> > Load Pack (support at ubikloadpack.com)</li>
> > > <li><bug>62473</bug>Setting
> > > "<code>saveservice_properties</code>"
> >
> > has counter intuitive behaviour</li>
> > > <li><bug>62354</bug>Correct calculation and usage of units
> > > for
> >
> > second per user (reported by jffagot05 at gmail.com)</li>
> > > + <li><bug>62700</bug>Introduce groovy.init.file to allow
> > > calling a
> >
> > groovy script on JMeter startup</li>
> > > <li><bug>62128</bug>Try to guess <code>JMETER_HOME</code>
> > > correctly,
> >
> > when <code>jmeter.bat</code> is called from a batch file in another
> > directory. Contributed by logox01 (logox01 at gmx.at)</li>
> > > <li><pr>386</pr>Add parameter support for RMI keystore
> > > creation
> >
> > scripts. Contributed by Logan Mauzaize (t524467 at
> > airfrance.fr)</li>
> > > <li><bug>62065</bug>Use Maven artifact for JAF Module instead
> > > of
> >
> > embedded module</li>
> > >
> > > Modified: jmeter/trunk/xdocs/usermanual/properties_reference.xml
> > > URL:
> >
> > http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/properti
> > es_reference.xml?rev=1840406&r1=1840405&r2=1840406&view=diff
> > >
> >
> > ===================================================================
> > ===========
> > > --- jmeter/trunk/xdocs/usermanual/properties_reference.xml
> > > (original)
> > > +++ jmeter/trunk/xdocs/usermanual/properties_reference.xml Sun
> > > Sep 9
> >
> > 13:09:21 2018
> > > @@ -1873,6 +1873,26 @@ JMETER-SERVER</source>
> > > </property>
> > > </properties>
> > > </section>
> > > +
> > > +<section name="§-num;.43 Advanced Groovy Scripting
> > > configuration"
> >
> > anchor="groovy">
> > > +<description>Advanced properties for configuration of scripting
> > > in
> >
> > Grooyv</description>
> > > +<properties>
> > > + <property name="groovy.init.file">
> > > + Path to Groovy file containing script to call on JMeter
> > > startup.
> >
> > <br/>
> > > + This script can use pre-defined variables:
> > > + <ul>
> > > + <li><code>log</code>: Logger to log any message, uses
> > > SLF4J
> >
> > library</li>
> > > + <li><code>props</code>: JMeter Properties</li>
> > > + <li><code>OUT</code>: System.OUT, useful to write in the
> >
> > console</li>
> > > + </ul>
> > > + No script is defined by default.
> > > + </property>
> > > + <property name="groovy.utilities">
> > > + Path to Groovy file containing utility functions to make
> > > available
> >
> > to __groovy function. <br/>
> > > + Defaults to <code>bin/utility.groovy</code>
> > > + </property>
> > > +</properties>
> > > +</section>
> > > <!--
> > > <section name="§-num;.10 Reports" anchor="Reports">
> > > <description>
> > >
> > >
> >
> >
>
>
Re: svn commit: r1840406 - in /jmeter/trunk: bin/jmeter.properties
src/core/org/apache/jmeter/JMeter.java xdocs/changes.xml xdocs/usermanual/properties_reference.xml
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello Felix, Sebb,
The idea for my commit, was that:
- It was proposed by a user
- I personally had to use it on a project, and it was weird to see I had to
use Beanshell to do that
- Since we advise to replace Beanshell by Groovy, we should have all
existing Beanshell features available as Groovy
Now regarding your remarks, I agree with you Felix that it would be nice.
But no firm position for me but:
- The risk I see with extension is that if file is misnamed , what shall we
do ?
- Sometimes we tend to be too open , making the software very customizable
, but more complex. This tend to complexify Learning curve and I have seen
this while giving trainings
- IMO, since we advise using Groovy for scripting, it would be logical that
we use it as a default. And since Javascript has bad performances, we
should avoid users using it, as such not provide opportunity to use it
(never, ever :-) )
But since I have no objection and might be wrong with my ideas, we can
introduce another property (but it would be one more among tens).
Note that Milamber was ready to start a release this sunday, so I don't
know if you are ready to provide a commit for it before he builds the
release
Regards
On Sun, Sep 9, 2018 at 3:19 PM Felix Schumacher <
felix.schumacher@internetallee.de> wrote:
> While I like groovy, it might be that other users have other JSR223
> languages as their favourites.
>
> 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?
>
> Felix
>
>
> Am 09.09.2018 um 15:09 schrieb pmouawad@apache.org:
> > Author: pmouawad
> > Date: Sun Sep 9 13:09:21 2018
> > New Revision: 1840406
> >
> > URL: http://svn.apache.org/viewvc?rev=1840406&view=rev
> > Log:
> > Bug 62700 - Introduce groovy.init.file to allow calling a groovy script
> on JMeter startup
> > Bugzilla Id: 62700
> >
> > Modified:
> > jmeter/trunk/bin/jmeter.properties
> > jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
> > jmeter/trunk/xdocs/changes.xml
> > jmeter/trunk/xdocs/usermanual/properties_reference.xml
> >
> > Modified: jmeter/trunk/bin/jmeter.properties
> > URL:
> http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.properties?rev=1840406&r1=1840405&r2=1840406&view=diff
> >
> ==============================================================================
> > --- jmeter/trunk/bin/jmeter.properties (original)
> > +++ jmeter/trunk/bin/jmeter.properties Sun Sep 9 13:09:21 2018
> > @@ -919,6 +919,13 @@ beanshell.server.file=../extras/startup.
> > # Groovy function
> >
> #---------------------------------------------------------------------------
> >
> > +# Path to Groovy file containing script to call on JMeter startup
> > +# This script can use pre-defined variables:
> > +# log : Logger to log any message
> > +# props : JMeter Property
> > +# OUT : System.OUT
> > +#groovy.init.file=
> > +
> > #Path to Groovy file containing utility functions to make available to
> __groovy function
> > #groovy.utilities=
> >
> >
> > Modified: jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
> > URL:
> http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/jmeter/JMeter.java?rev=1840406&r1=1840405&r2=1840406&view=diff
> >
> ==============================================================================
> > --- jmeter/trunk/src/core/org/apache/jmeter/JMeter.java (original)
> > +++ jmeter/trunk/src/core/org/apache/jmeter/JMeter.java Sun Sep 9
> 13:09:21 2018
> > @@ -22,6 +22,7 @@ import java.awt.event.ActionEvent;
> > import java.io.File;
> > import java.io.FileInputStream;
> > import java.io.FileNotFoundException;
> > +import java.io.FileReader;
> > import java.io.IOException;
> > import java.io.InputStream;
> > import java.net.Authenticator;
> > @@ -44,6 +45,10 @@ import java.util.StringTokenizer;
> > import java.util.concurrent.TimeUnit;
> > import java.util.concurrent.atomic.AtomicInteger;
> >
> > +import javax.script.Bindings;
> > +import javax.script.ScriptEngine;
> > +import javax.script.ScriptEngineManager;
> > +import javax.script.ScriptException;
> > import javax.swing.JTree;
> > import javax.swing.UIManager;
> > import javax.swing.tree.TreePath;
> > @@ -634,23 +639,7 @@ public class JMeter implements JMeterPlu
> > t.run(); // NOSONAR we just evaluate some code here
> > }
> >
> > - // Should we run a beanshell script on startup?
> > - String bshinit =
> JMeterUtils.getProperty("beanshell.init.file");// $NON-NLS-1$
> > - if (bshinit != null){
> > - log.info("Run Beanshell on file: {}", bshinit);
> > - try {
> > - BeanShellInterpreter bsi = new BeanShellInterpreter();
> > - bsi.source(bshinit);
> > - } catch (ClassNotFoundException e) {
> > - if (log.isWarnEnabled()) {
> > - log.warn("Could not start Beanshell: {}",
> e.getLocalizedMessage());
> > - }
> > - } catch (JMeterException e) {
> > - if (log.isWarnEnabled()) {
> > - log.warn("Could not process Beanshell file: {}",
> e.getLocalizedMessage());
> > - }
> > - }
> > - }
> > + runInitScripts();
> >
> > int
> mirrorPort=JMeterUtils.getPropDefault("mirror.server.port", 0);//
> $NON-NLS-1$
> > if (mirrorPort > 0){
> > @@ -665,6 +654,51 @@ public class JMeter implements JMeterPlu
> > }
> > }
> > }
> > +
> > +
> > + /**
> > + * Runs user configured init scripts
> > + */
> > + void runInitScripts() {
> > + // Should we run a beanshell script on startup?
> > + String bshinit =
> JMeterUtils.getProperty("beanshell.init.file");// $NON-NLS-1$
> > + if (bshinit != null){
> > + log.info("Running Beanshell on file: {}", bshinit);
> > + try {
> > + BeanShellInterpreter bsi = new BeanShellInterpreter();
> > + bsi.source(bshinit);
> > + } catch (ClassNotFoundException|JMeterException e) {
> > + if (log.isWarnEnabled()) {
> > + log.warn("Could not process Beanshell file: {}",
> e.getMessage());
> > + }
> > + }
> > + }
> > +
> > + // Should we run a Groovy script on startup?
> > + String jsr223Init =
> JMeterUtils.getProperty("groovy.init.file");// $NON-NLS-1$
> > + if (jsr223Init != null){
> > + log.info("Running Groovy init script in file: {}",
> jsr223Init);
> > + File file = new File(jsr223Init);
> > + if(file.exists() && file.canRead()) {
> > + try (FileReader reader = new FileReader(file)) {
> > + ScriptEngineManager scriptEngineManager = new
> ScriptEngineManager();
> > + ScriptEngine engine =
> scriptEngineManager.getEngineByName("Groovy");
> > + Bindings bindings = engine.createBindings();
> > + final Logger logger =
> LoggerFactory.getLogger("groovy.init.file");
> > + bindings.put("log", logger); // $NON-NLS-1$ (this
> name is fixed)
> > + Properties props =
> JMeterUtils.getJMeterProperties();
> > + bindings.put("props", props); // $NON-NLS-1$ (this
> name is fixed)
> > + // For use in debugging:
> > + bindings.put("OUT", System.out); // NOSONAR
> $NON-NLS-1$ (this name is fixed)
> > + engine.eval(reader, bindings);
> > + } catch (IOException | ScriptException ex) {
> > + log.error("Error running init script referenced by
> property {}", jsr223Init, ex);
> > + }
> > + } else {
> > + log.error("Script {}Â referenced by property {}Â is not
> readable or does not exists", file.getAbsolutePath(), jsr223Init);
> > + }
> > + }
> > + }
> >
> > /**
> > * Sets a proxy server for the JVM if the command line arguments
> are
> >
> > Modified: jmeter/trunk/xdocs/changes.xml
> > URL:
> http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes.xml?rev=1840406&r1=1840405&r2=1840406&view=diff
> >
> ==============================================================================
> > --- jmeter/trunk/xdocs/changes.xml [utf-8] (original)
> > +++ jmeter/trunk/xdocs/changes.xml [utf-8] Sun Sep 9 13:09:21 2018
> > @@ -160,6 +160,7 @@ this behaviour, set <code>httpclient.res
> > <li><bug>62470</bug>CSV Output : Enable logging of sub results when
> <code>jmeter.save.saveservice.subresults=true</code>. Contributed by Ubik
> Load Pack (support at ubikloadpack.com)</li>
> > <li><bug>62473</bug>Setting "<code>saveservice_properties</code>"
> has counter intuitive behaviour</li>
> > <li><bug>62354</bug>Correct calculation and usage of units for
> second per user (reported by jffagot05 at gmail.com)</li>
> > + <li><bug>62700</bug>Introduce groovy.init.file to allow calling a
> groovy script on JMeter startup</li>
> > <li><bug>62128</bug>Try to guess <code>JMETER_HOME</code> correctly,
> when <code>jmeter.bat</code> is called from a batch file in another
> directory. Contributed by logox01 (logox01 at gmx.at)</li>
> > <li><pr>386</pr>Add parameter support for RMI keystore creation
> scripts. Contributed by Logan Mauzaize (t524467 at airfrance.fr)</li>
> > <li><bug>62065</bug>Use Maven artifact for JAF Module instead of
> embedded module</li>
> >
> > Modified: jmeter/trunk/xdocs/usermanual/properties_reference.xml
> > URL:
> http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/properties_reference.xml?rev=1840406&r1=1840405&r2=1840406&view=diff
> >
> ==============================================================================
> > --- jmeter/trunk/xdocs/usermanual/properties_reference.xml (original)
> > +++ jmeter/trunk/xdocs/usermanual/properties_reference.xml Sun Sep 9
> 13:09:21 2018
> > @@ -1873,6 +1873,26 @@ JMETER-SERVER</source>
> > </property>
> > </properties>
> > </section>
> > +
> > +<section name="§-num;.43 Advanced Groovy Scripting configuration"
> anchor="groovy">
> > +<description>Advanced properties for configuration of scripting in
> Grooyv</description>
> > +<properties>
> > + <property name="groovy.init.file">
> > + Path to Groovy file containing script to call on JMeter startup.
> <br/>
> > + This script can use pre-defined variables:
> > + <ul>
> > + <li><code>log</code>: Logger to log any message, uses SLF4J
> library</li>
> > + <li><code>props</code>: JMeter Properties</li>
> > + <li><code>OUT</code>: System.OUT, useful to write in the
> console</li>
> > + </ul>
> > + No script is defined by default.
> > + </property>
> > + <property name="groovy.utilities">
> > + Path to Groovy file containing utility functions to make available
> to __groovy function. <br/>
> > + Defaults to <code>bin/utility.groovy</code>
> > + </property>
> > +</properties>
> > +</section>
> > <!--
> > <section name="§-num;.10 Reports" anchor="Reports">
> > <description>
> >
> >
>
>
--
Cordialement.
Philippe Mouawad.
Re: svn commit: r1840406 - in /jmeter/trunk: bin/jmeter.properties src/core/org/apache/jmeter/JMeter.java xdocs/changes.xml xdocs/usermanual/properties_reference.xml
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 12. September 2018 22:16:33 MESZ schrieb Philippe Mouawad <p....@ubik-ingenierie.com>:
>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.
I could do it in the evening.
Regards,
Felix
>Regards
>
>On Wednesday, September 12, 2018, Philippe Mouawad <
>p.mouawad@ubik-ingenierie.com> 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 <se...@gmail.com> wrote:
>>
>>> On 9 September 2018 at 16:16, Felix Schumacher
>>> <fe...@internetallee.de> wrote:
>>> >
>>> >
>>> > Am 09.09.2018 um 16:31 schrieb sebb:
>>> >>
>>> >> On 9 September 2018 at 14:55, Felix Schumacher
>>> >> <fe...@internetallee.de> wrote:
>>> >>>
>>> >>> Am Sonntag, den 09.09.2018, 14:41 +0100 schrieb sebb:
>>> >>>>
>>> >>>> On 9 September 2018 at 14:19, Felix Schumacher
>>> >>>> <fe...@internetallee.de> 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>
>>
>>
Re: svn commit: r1840406 - in /jmeter/trunk: bin/jmeter.properties
src/core/org/apache/jmeter/JMeter.java xdocs/changes.xml xdocs/usermanual/properties_reference.xml
Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
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 <
p.mouawad@ubik-ingenierie.com> 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 <se...@gmail.com> wrote:
>
>> On 9 September 2018 at 16:16, Felix Schumacher
>> <fe...@internetallee.de> wrote:
>> >
>> >
>> > Am 09.09.2018 um 16:31 schrieb sebb:
>> >>
>> >> On 9 September 2018 at 14:55, Felix Schumacher
>> >> <fe...@internetallee.de> wrote:
>> >>>
>> >>> Am Sonntag, den 09.09.2018, 14:41 +0100 schrieb sebb:
>> >>>>
>> >>>> On 9 September 2018 at 14:19, Felix Schumacher
>> >>>> <fe...@internetallee.de> 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>
Re: svn commit: r1840406 - in /jmeter/trunk: bin/jmeter.properties
src/core/org/apache/jmeter/JMeter.java xdocs/changes.xml xdocs/usermanual/properties_reference.xml
Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
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 <se...@gmail.com> wrote:
> On 9 September 2018 at 16:16, Felix Schumacher
> <fe...@internetallee.de> wrote:
> >
> >
> > Am 09.09.2018 um 16:31 schrieb sebb:
> >>
> >> On 9 September 2018 at 14:55, Felix Schumacher
> >> <fe...@internetallee.de> wrote:
> >>>
> >>> Am Sonntag, den 09.09.2018, 14:41 +0100 schrieb sebb:
> >>>>
> >>>> On 9 September 2018 at 14:19, Felix Schumacher
> >>>> <fe...@internetallee.de> 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>
Re: svn commit: r1840406 - in /jmeter/trunk: bin/jmeter.properties
src/core/org/apache/jmeter/JMeter.java xdocs/changes.xml xdocs/usermanual/properties_reference.xml
Posted by sebb <se...@gmail.com>.
On 9 September 2018 at 16:16, Felix Schumacher
<fe...@internetallee.de> wrote:
>
>
> Am 09.09.2018 um 16:31 schrieb sebb:
>>
>> On 9 September 2018 at 14:55, Felix Schumacher
>> <fe...@internetallee.de> wrote:
>>>
>>> Am Sonntag, den 09.09.2018, 14:41 +0100 schrieb sebb:
>>>>
>>>> On 9 September 2018 at 14:19, Felix Schumacher
>>>> <fe...@internetallee.de> 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
>
>
Re: svn commit: r1840406 - in /jmeter/trunk: bin/jmeter.properties
src/core/org/apache/jmeter/JMeter.java xdocs/changes.xml
xdocs/usermanual/properties_reference.xml
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 09.09.2018 um 16:31 schrieb sebb:
> On 9 September 2018 at 14:55, Felix Schumacher
> <fe...@internetallee.de> wrote:
>> Am Sonntag, den 09.09.2018, 14:41 +0100 schrieb sebb:
>>> On 9 September 2018 at 14:19, Felix Schumacher
>>> <fe...@internetallee.de> 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
Re: svn commit: r1840406 - in /jmeter/trunk: bin/jmeter.properties
src/core/org/apache/jmeter/JMeter.java xdocs/changes.xml xdocs/usermanual/properties_reference.xml
Posted by sebb <se...@gmail.com>.
On 9 September 2018 at 14:55, Felix Schumacher
<fe...@internetallee.de> wrote:
> Am Sonntag, den 09.09.2018, 14:41 +0100 schrieb sebb:
>> On 9 September 2018 at 14:19, Felix Schumacher
>> <fe...@internetallee.de> 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
Re: svn commit: r1840406 - in /jmeter/trunk: bin/jmeter.properties
src/core/org/apache/jmeter/JMeter.java xdocs/changes.xml
xdocs/usermanual/properties_reference.xml
Posted by Felix Schumacher <fe...@internetallee.de>.
Am Sonntag, den 09.09.2018, 14:41 +0100 schrieb sebb:
> On 9 September 2018 at 14:19, Felix Schumacher
> <fe...@internetallee.de> 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
Re: svn commit: r1840406 - in /jmeter/trunk: bin/jmeter.properties
src/core/org/apache/jmeter/JMeter.java xdocs/changes.xml xdocs/usermanual/properties_reference.xml
Posted by sebb <se...@gmail.com>.
On 9 September 2018 at 14:19, Felix Schumacher
<fe...@internetallee.de> 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
If the code ignored missing *.init.file properties, then
jsr223.init.languages could default to beanshell in order to keep the
existing behaviour.