Skip to main content

Using grinder 3.4 and jython 2.5.1

By default grinder 3.4 comes with a jython jar under lib directory. It is version 2.2.1. In order two use a newer jython, you need to change two settings:
  • add your newest jython jar in front of classpath
  • add a jvm property that directs python_home to the home of your jython.
You can either do this in grinder.properties or in your bat script that starts the agent. I prefer the latter as I would like to keep grinder.properties as general as possible, independent of machines/environment. My new startAgent_jython251.cmd script looks like:
@echo off
set GRINDERPATH=C:\development\grinder-3.4
call %GRINDERPATH%\setGrinderEnv.cmd
set PYTHON_HOME=C:/development/jython2.5.1
echo %CLASSPATH%
set CLASSPATH=%PYTHON_HOME%/jython.jar;%CLASSPATH%
set JVMARGS="-Dpython.home=%PYTHON_HOME% -Dpython.cachedir=%GRINDERPATH%/cachedir"
java -Duser.language="en" -Dgrinder.jvm.arguments=%JVMARGS% -cp %CLASSPATH% net.grinder.Grinder %GRINDERPROPERTIES%
When I run a script with this agent cmd, my output looks like:
04.06.10 13:53:46 (process emeafralp560-0): The Grinder version 3.4
04.06.10 13:53:46 (process emeafralp560-0): Java(TM) SE Runtime Environment 1.6.0_20-b02: Java HotSpot(TM) Client VM (16.3-b01, mixed mode) on Windows XP x86 5.1
04.06.10 13:53:46 (process emeafralp560-0): time zone is MESZ (+0200)
04.06.10 13:53:48 (process emeafralp560-0): worker process 0
04.06.10 13:53:48 (process emeafralp560-0): instrumentation agents: byte code transforming instrumenter for Jython 2.5; byte code transforming instrumenter for Java
04.06.10 13:53:48 (process emeafralp560-0): executing "C:\development\grinder-3.4\HelloGrinder3.py" using Jython 2.5.1 (Release_2_5_1:6813, Sep 26 2009, 13:47:54) 
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)]
I think that by default it is already using the new instrumentation implementation that gets used by jython 2.5.1. Manual states namely that if you use the old one, the output shows you
traditional Jython instrumenter
I did not see it, and could not influence the output with parameter
grinder.dcrinstrumentation = true
So I compared behaviour with a grinder using jython 2.2.1. There using this parameter did make an influence. If you included the parameter, regardless the value you are giving it (true|anything|even-false|false), it will use the new way of instrumentation. Only when you leave the parameter out, you will get output:
04.06.10 14:00:34 (process emeafralp560-0): The Grinder version 3.4
04.06.10 14:00:34 (process emeafralp560-0): Java(TM) SE Runtime Environment 1.6.0_20-b02: Java HotSpot(TM) Client VM (16.3-b01, mixed mode) on Windows XP x86 5.1
04.06.10 14:00:34 (process emeafralp560-0): time zone is MESZ (+0200)
04.06.10 14:00:34 (process emeafralp560-0): worker process 0
04.06.10 14:00:34 (process emeafralp560-0): instrumentation agents: traditional Jython instrumenter; byte code transforming instrumenter for Java
04.06.10 14:00:34 (process emeafralp560-0): executing "C:\development\grinder-3.4\HelloGrinder3.py" using Jython 2.2.1

Comments

Popular posts from this blog

SSL handshake failed: Secure connection truncated

Got this problem on Ubuntu 9.10 and 10.10. svn co --username=xx https:/yy zz “SSL handshake failed: Secure connection truncated” According to this link bug-ubuntu The solution is: sudo apt-get install libneon27 cd /usr/lib/ sudo rm libneon-gnutls.so.27 sudo ln -s /usr/lib/libneon.so.27 libneon-gnutls.so.27

Junit4 running parallel junit classes

To run junit testcases parallel, you can create your own class to run junit with: Add this tag to your class declaration. @RunWith(Parallelized.class) Implementation of this class looks like: package mypackage; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; import org.junit.runners.Parameterized; import org.junit.runners.model.RunnerScheduler; public class Parallelized extends Parameterized {         private static class ThreadPoolScheduler implements RunnerScheduler     {         private ExecutorService executor;                 public ThreadPoolScheduler()         {             String threads = System.getProperty("junit.parallel.threads", "16");    ...

Create a groovy console and bind to selenium

Required groovy files In the previous posting we defined the pom file that we need for our build environment. Now we will setup some groovy files to get selenium and groovy running interactively. ConsoleWaiter.groovy The idea of Groovy Console I found on some other sides. Honour goes for instance too: http://josefbetancourt.wordpress.com/tag/eclipse-2/ I copied some code of this, and put it under src/test/groovy/com/jankester/selenium/test/utils: package com.jankester.selenium.test.utils /** * File: ConsoleWaiter.groovy */ import groovy.lang.Binding; import groovy.ui.Console; /** * Provides a wrapper for the console. * * Based on source by John Green * Adapted from: http://www.oehive.org/files/ConsoleWaiter.groovy * Released under the Eclipse Public License * http://www.eclipse.org/legal/epl-v10.html * * I added methods to allow use from Java. * * The run() method launches the console and causes this thread * to sleep until the console's window is closed....