-
1. Re: Design Discussion: maven-byteman-plugin
Hi Chris,
Dunno about maven but the ant scripts which drive the JBossTS build process run some of the JBossTS junit tests with a byteman agent installed. W ehave a run.tests macro which takes a script attribute. If present it runs up juint with the agent installed. Here is an extract from https://svn.jboss.org/repos/labs/labs/jbosstm/trunk/ArjunaCore/arjuna/build.xml which gives an example of how to use the ant macro form the ArjunaCore unit tests:<target name="run.tests"> . . . </run.tests.macro> <!-- reaper tests run using script reaper.txt --> <run.tests.macro script="reaper.txt"> <tests> <fileset dir="tests/classes"> <include name="**/reaper/ReaperMonitorTest.java"/> <include name="**/reaper/ReaperTestCase.java"/> <include name="**/reaper/ReaperTestCase2.java"/> <include name="**/reaper/ReaperTestCase3.java"/> </fileset> </tests> <!--<additional.jvmargs>--> <!--<jvmarg value="-Dorg.jboss.byteman.dump.generated.classes"/>--> <!--<jvmarg value="-Dorg.jboss.byteman.dump.generated.classes.directory=dump"/>--> <!--<jvmarg value="-Xdebug"/>--> <!--<jvmarg value="-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"/>--> <!--</additional.jvmargs>--> </run.tests.macro> . . . </target>
The macro definition is included from https://svn.jboss.org/repos/labs/labs/jbosstm/trunk/sharedbuild.xml<macrodef name="run.tests.macro"> <attribute name="script" default=""/> <attribute name="showoutput" default="false"/> <element name="tests"/> <element name="additional.classpath" optional="true"/> <element name="additional.jvmargs" optional="true"/> <sequential> <if> <equals arg1="@{script}" arg2=""/> <then> <run.tests.macro.aux showoutput="@{showoutput}"> <tests.aux> <tests/> </tests.aux> <additional.classpath.aux> <additional.classpath/> </additional.classpath.aux> <additional.jvmargs.aux> <additional.jvmargs/> </additional.jvmargs.aux> </run.tests.macro.aux> </then> <else> <run.tests.macro.aux showoutput="@{showoutput}"> <tests.aux> <tests/> </tests.aux> <additional.classpath.aux> <additional.classpath/> </additional.classpath.aux> <additional.jvmargs.aux> <jvmarg value="-javaagent:${global.ext.lib.dir}/byteman.jar=script:${basedir}/tests/byteman-scripts/@{script}"/> <jvmarg value="-Dorg.jboss.byteman.debug"/> <additional.jvmargs/> </additional.jvmargs.aux> </run.tests.macro.aux> </else> </if> </sequential> </macrodef> <macrodef name="run.tests.macro.aux"> <attribute name="showoutput" default="false"/> <element name="tests.aux"/> <element name="additional.classpath.aux" optional="true"/> <element name="additional.jvmargs.aux" optional="true"/> <sequential> <echo file="${build.dir}/tests/jbossts-properties.xml" message="<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd"><properties/>"/> <copy file="${sharedbuild.base.dir}/ArjunaCore/arjuna/etc/log4j.properties" todir="${build.dir}/classes"/> <mkdir dir="${build.dir}/testresults"/> <junit printsummary="yes" fork="yes" dir="${build.dir}" showoutput="@{showoutput}" > <formatter type="plain"/> <classpath> <pathelement location="etc"/> <pathelement location="${build.dir}/lib/${modulename}.jar"/> <!--<pathelement location="${build.dir}/classes/"/>--> <pathelement location="${build.dir}/tests/"/> <fileset dir="${build.dir}/lib/ext/" includes="*"/> <fileset dir="${basedir}" includes="${lib.dir}/ext/*"/> <fileset dir="${global.ext.lib.dir}" includes="${global.ext.libs}"/> <fileset dir="${global.ext.lib.dir}" includes="${global.ext.test.libs}"/> <fileset dir="${global.ext.lib.dir}" includes="commons-logging-1.1.jar,log4j*"/> <additional.classpath.aux/> </classpath> <batchtest haltonerror="yes" haltonfailure="yes" fork="yes" todir="${build.dir}/testresults"> <tests.aux/> </batchtest> <additional.jvmargs.aux/> </junit> </sequential> </macrodef> -
2. Design Discussion: maven-byteman-plugin
Chris:
Did you ever make any progress on this? I'm using Maven for all my builds, and would like i) an easier way to incorporate Byteman into unit tests and ii) have those same JUnit tests run correctly in Eclipse. Ideally I'd like to configure Byteman via a simple Maven plugin and then use the BMUnit annotations in the unit test source.
Anyone
-
3. Design Discussion: maven-byteman-plugin
Hi Randall,
If you want to use BMUnit then it is almost possible to get it to work in maven -- you can certainly make it work but the problem is getting maven to set up the load dependencies without you having to separately download and install the byteman release. If you can help me identify what is needed to fix this then I will be happy to make any necessary changes to Byteman to get it automated.
The first requirement is simple. BMUnit requires you to have byteman-bmunit.jar, byteman-install.jar and byteman-submit.jar in the test classpath. You can just make these jars test dependencies (the 1.5.0 jars which include the JUnit integration are in the JBoss maven repo) and maven will make them available.
There are two other requirements which are slightly more difficult to resolve. Firstly, you need the JDK jar tools.jar in the test classpath. This is a little tricky to automate because this jar only exists in a JDK, not a JRE. It should be found in ${JAVA_HOME}/lib. If you can work out a portable way to set up maven tests so that ${JAVA_HOME}/lib/tools.jar is in the classpath then this will allow BMUnit to use the VMMachine.attach API to load the agent into the test JVM automatically.
You also need to make the code in byteman.jar available to your tests but putting this jar in the classpath is not enough. The agent installer code used by BMUnit wil automatically load the agent at runtime but it has to locate the agent jar and load it explicitly. Currently, it uses either environment variable BYTEMAN_HOME or System property org.jboss.byteman.home to locate a root directory, let's call it /path/to/bmhome, and then tries to load the agent from directory /path/to/bmhome/lib/byteman.jar. I assume you must be able to configure the maven test plugin to define one or other of these. The problem is how to ensure that the relevant byteman jar is installed in a suitable location. I can easily change the lookup procedure (e.g. to remove the need for a lib subdirectory). But even then I woudl not know how to configure a maven test so that it can be found in the appropriate location in the maven repo. I think it might be possible for the agent to be able to locate the jar using the classpath if ti can rely on System property java.class.path inlcuding a reference to the jar. I will take a look at seeing how to do this.
It is also possible to avoid using BMUnit to load the agent and instead explicitly load it into the test JVM at startup. If you ensure that System property org.jboss.byteman.contrib.bmunit.agent.inhibit is set in the test JVM then BMUnit will not try to perform the agent load. This still means you would have to run the java command using option -javaagent if you wanted BMUnit to work. Of course, this requires you to provide an explicit reference to byteman.jar as the first argument to this java option, so it does not get you any further forward.
-
4. Design Discussion: maven-byteman-plugin
I think I got this to work. In the POM file for my Maven project, I added these dependencies:
<!--
Byteman Dependencies
-->
<dependency>
<groupId>org.jboss.byteman</groupId>
<artifactId>byteman-bmunit</artifactId>
<version>1.5.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jboss.byteman</groupId>
<artifactId>byteman-install</artifactId>
<version>1.5.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jboss.byteman</groupId>
<artifactId>byteman-install</artifactId>
<version>1.5.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jboss.byteman</groupId>
<artifactId>byteman-submit</artifactId>
<version>1.5.0</version>
<scope>test</scope>
</dependency>
and then defined the Surefire configuration as follows:
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
<executions>
<execution>
<id>integration-test</id>
<phase>integration-test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<systemProperties>
<property>
<name>org.jboss.byteman.home</name>
<value>/Users/rhauch/Desktop/byteman-1.5.0</value>
</property>
<property>
<name>org.jboss.byteman.verbose</name>
<value>true</value>
</property>
<property>
<name>org.jboss.byteman.contrib.bmunit.verbose</name>
<value>true</value>
</property>
</systemProperties>
<skip>false</skip>
<additionalClasspathElements>
<additionalClasspathElement>${java.home}/lib/tools.jar</additionalClasspathElement>
</additionalClasspathElements>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
(Note that this is an integration test module, thus the "skip" element in the configuration. This is a bit of a hack to get Surefire to run at a later phase, but it works, and doesn't really have anything to do with Byteman.)
Now, this still requires a separate installation of Byteman, but I was thinking of moving that into my Maven project. This is very non-standard, but it gets around the separate Byteman installation and should theoretically work in Hudson. Yes, this a very much a hack.
As for running the JUnit tests within Eclipse, unfortunately the Eclipse JUnit plugin doesn't read or use the Maven Surefire configuration, so Eclipse has to be set up differently. I created a launch configuration for each of my test classes, added the BYTEMAN_HOME variable, and shared them to my Maven project so others getting the code and using Eclipse should automatically get these launch configurations. Luckily on Mac OS-X, the "tools.jar" is automatically included, so I didn't have to change the JRE/JDK installation in Eclipse. (It took me a while to figure this out.) Developers running on other operating systems would have to edit their JRE installation in Eclipse (which really should point to a JDK installation) and manually add the "tools.jar" file.
I think with this approach, I get everything I want: other contributors just get the code from Git, run a build using Maven, or in Eclipse run individual unit tests (via the shared launch configurations). It's just not terribly pretty, especially with having the Byteman installation in the Maven project codebase. This is the only way I could think of to not require the developer to manually install Byteman (ensuring the installed version is compatible with the version of the BMUnit, install, and submit dependencies in the code).
Ideally, the Byteman Maven plugin would be able to do/have the installation of Byteman itself (perhaps the version is configured by a plugin property, or better yet automatically identified from the 'byteman-bmunit' dependency version, and downloaded automatically via the Maven repository), and then somehow modify the Surefire configuration to add the system properties. Maybe just modifying the system properties prior to delegating to the Surefire plugin might be sufficient??
-
5. Re: Design Discussion: maven-byteman-plugin
Randall Hauch wrote:
I think I got this to work. In the POM file for my Maven project, I added these dependencies:
. . .
Now, this still requires a separate installation of Byteman, but I was thinking of moving that into my Maven project. This is very non-standard, but it gets around the separate Byteman installation and should theoretically work in Hudson. Yes, this a very much a hack.It's still pretty good though :-). Congratulations! and thanks for pushing it this far.
I think I may be able to help you avoid the need to separately install byteman though. Any JVM should have access to the classpath via the System property java.class.path. So, when the test JVM is started by maven I believe this ought to include all the jars labelled as test dependencies. So, I might be able to tweak the agent install routine to search this path and look for an entry with jar name byteman.jar. If found I could use this as the agent jar. Otherwise I coudl still use BYTEMAN_HOME or org.jboss.byteman.home. If this works then you should be able to include the byteman jar as a test dependency and have it installed automatically.
I'll try rig up a simple maven test to see if it I can find the jar via the system property. If so then I will fix the agent install in byteman trunk. and then push out a 1.5.1 release ASAP.
-
6. Re: Design Discussion: maven-byteman-plugin
Hi Randall,
I am able to locate the byteman jar in System.getProperty("java.class.path") when it is included as a maven dependency. Actually, this ought to be true whatever is being used to run the tests (e.g. JUnit under ant, TestNG run directly). So, for release 1.5.1 I I will update the agent installer to use any byteman jar it canfind in the classpath unless directed to do otherwise by a BYTEMAN_HOME or org.jboss.byteman.home setting. I can make the installer accept any jar with a name like byteman.jar or byteman-L.M.N.jar or byteman-L.M.N-SNAPSHOT.jar. This should mean that you just need to have the four byteman jars and the tools jar as test dependencies for BMUnit to work.
Here is the JIRA
https://issues.jboss.org/browse/BYTEMAN-149
regards,
Andrew Dinn
-
7. Re: Design Discussion: maven-byteman-plugin
That sounds fantastic, Andrew.
If I understand the proposed changes, with 1.5.1 I'd just need to add Maven dependencies for the "byteman-bmunit", "byteman-install", "byteman-submit", and "byteman" artifacts, and I'd need nothing Byteman-specific in the Surefire configuration or Eclipse launch configurations. That would dramatically lower the bar for using Byteman in unit tests!!
What do you estimate as the next release date?
-
8. Re: Design Discussion: maven-byteman-plugin
Hi Randall,
Randall Hauch wrote:
If I understand the proposed changes, with 1.5.1 I'd just need to add Maven dependencies for the "byteman-bmunit", "byteman-install", "byteman-submit", and "byteman" artifacts, and I'd need nothing Byteman-specific in the Surefire configuration or Eclipse launch configurations. That would dramatically lower the bar for using Byteman in unit tests!!
Yes, that's the plan -- of course, you also need the tools jar in your test path. i.e. you need the single config property
<additionalClasspathElements>
<additionalClasspathElement>${java.home}/lib/tools.jar</additionalClasspathElement>
</additionalClasspathElements>
I'm just about to test the fix I added to trunk last night with a 1.5.1-SNAPSHOT build to be sure this really works. Fingers crossed :-)
Randall Hauch wrote:
What do you estimate as the next release date?
Well, I could churn out a 1.5.1 patch release today -- it woudl be really nice if Byteman testing in maven was this simple.
I'll talk to Scott first to see how he is getting on with adding a BMConfig annotation to BMUnit. This was scheduled to go into 1.5.1. If he is close to ready then we might wait a few days to get that in too. However, I can always add his stuff to a later patch release (releasing is pretty easy to do). I'll get back to you when I have talked to Scott.
-
9. Re: Design Discussion: maven-byteman-plugin
Hi Randall,
I just tested my fixes from last night and it all appears to work. If you would like to test it you can consume the 1.5.1-SNAPSHOT release from the JBoss snapshots repo. My test project pom is as follows
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>mvntest</groupId> <artifactId>mvntest</artifactId> <version>1.0</version> <packaging>jar</packaging> <properties> <byteman-version>1.5.1-SNAPSHOT</byteman-version> <java.home>/usr/java/jdk1.6.0_21</java.home> </properties> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.0.2</version> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.5</version> <configuration> <additionalClasspathElements> <additionalClasspathElement>${java.home}/lib/tools.jar</additionalClasspathElement> </additionalClasspathElements> </configuration> </plugin> </plugins> </build> <!-- Byteman Dependencies --> <dependencies> <dependency> <groupId>org.jboss.byteman</groupId> <artifactId>byteman</artifactId> <version>${byteman-version}</version> <scope>test</scope> </dependency> <dependency> <groupId>org.jboss.byteman</groupId> <artifactId>byteman-install</artifactId> <version>${byteman-version}</version> <scope>test</scope> </dependency> <dependency> <groupId>org.jboss.byteman</groupId> <artifactId>byteman-install</artifactId> <version>${byteman-version}</version> <scope>test</scope> </dependency> <dependency> <groupId>org.jboss.byteman</groupId> <artifactId>byteman-submit</artifactId> <version>${byteman-version}</version> <scope>test</scope> </dependency> <dependency> <groupId>org.jboss.byteman</groupId> <artifactId>byteman-bmunit</artifactId> <version>${byteman-version}</version> <scope>test</scope> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.8.1</version> <scope>test</scope> </dependency> </dependencies> </project>The project includes the following class:
public class MvnCheck { private String name; public MvnCheck(String name) { this.name = name; } public String getName() { return name; } public void testOne() throws Exception { // intercepted by Byteman throw new Exception("Failed ot intercept testOne"); } public void testTwo(int i) throws Exception { // i should be reset by Byteman if (i == 0) { throw new Exception("Failed to intercept testTwo"); } } }and the following test class annotated with the RunWith and BMRule anotations
@RunWith(BMUnitRunner.class) @BMRule(name="return from testOne at entry", targetClass = "MvnCheck", targetMethod = "testOne()", action = "traceln(\"intercepted \" + $0.getName() + \".testOne()\"); return;") public class MvnTest { @BMRule(name="reset testTwo arg at entry", targetClass = "MvnCheck", targetMethod = "testTwo(int)", action = "traceln(\"intercepted \" + $0.getName() + \".testTwo(\" + $1 + \")\"); $1 = $1 + 1;") @Test public void testBMUnit() throws Exception { MvnCheck mvnCheck = new MvnCheck("Chubby Checker"); mvnCheck.testOne(); mvnCheck.testTwo(0); } }The mvn test output is
------------------------------------------------------- T E S T S ------------------------------------------------------- Running MvnTest intercepted Chubby Checker.testOne() intercepted Chubby Checker.testTwo(0) Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.534 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
The only annoying thing is that I had to specify java.home explicitly in the pom. Is there a way to set this mvn property from the env value $JAVA_HOME?
-
10. Re: Design Discussion: maven-byteman-plugin
The only annoying thing is that I had to specify java.home explicitly in the pom. Is there a way to set this mvn property from the env value $JAVA_HOME?
I thought that "
${java.home}" is supposed to be set by Maven. What Maven version are you using? -
11. Re: Design Discussion: maven-byteman-plugin
I just saw this:
- env.X: Prefixing a variable with "env." will return the shell's environment variable. For example, ${env.PATH} contains the PATH environment variable. Note: While environment variables themselves are case-insensitive on Windows, lookup of properties is case-sensitive. In other words, while the Windows shell returns the same value for %PATH% and %Path%, Maven distinguishes between ${env.PATH} and ${env.Path}. As of Maven 2.1.0, the names of environment variables are normalized to all upper-case for the sake of reliability.
- project.x: A dot (.) notated path in the POM will contain the corresponding element's value. For example: <project><version>1.0</version></project> is accessible via ${project.version}.
- settings.x: A dot (.) notated path in the settings.xml will contain the corresponding element's value. For example: <settings><offline>false</offline></settings> is accessible via${settings.offline}.
- Java System Properties: All properties accessible via java.lang.System.getProperties() are available as POM properties, such as ${java.home}.
- x: Set within a <properties /> element. The value may be used as ${someVar}.
So maybe "${env.JAVA_HOME}" will work?? But everything I'm reading suggests that "${java.home}" should be set automatically by Maven.
-
12. Re: Design Discussion: maven-byteman-plugin
Hi Randall,
Randall Hauch wrote:
. . .
So maybe "${env.JAVA_HOME}" will work?? But everything I'm reading suggests that "${java.home}" should be set automatically by Maven.
Yes, ${env.JAVA_HOME} will work.
I also worked out why ${java.home} does not work. When I run maven (whether it is 2.0.10, 3.0.Beta or 3.0.2) I have JAVA_HOME set to /usr/java/jdk1.6.0_21 i.e. it locates my installed JDK. However, maven is initialising property java.home to /usr/java/jdk1.6.0_21/jre i.e. it is advertising the installed JRE. The tools jar can be found if I set the additional classpath entry to ${java.home}/../lib/tools.jar.
The phrase 'steaming heap of dingos kidneys' does spring to mind. Still at least it now works :-)
-
13. Design Discussion: maven-byteman-plugin
This feature is now available in Byteman release 1.5.1. For maven inetgration simply add dependencies on the 1.5.1 jars which ar in the JBoss repository. For ant integration just ensure the required byteman jars are in the classpath. :-)
-
14. Design Discussion: maven-byteman-plugin
I've started using Byteman 1.5.1 (thanks, btw!), and everything works great in Eclipse and in Maven using Surefire as long as I use this configuration for the Surefire plugin:
<configuration>
<systemProperties>
<property>
<name>org.jboss.byteman.contrib.bmunit.verbose</name>
<value>false</value>
</property>
</systemProperties>
<skip>false</skip>
<additionalClasspathElements>
<additionalClasspathElement>${env.JAVA_HOME}/lib/tools.jar</additionalClasspathElement>
</additionalClasspathElements>
</configuration>
However, if I remove the "systemProperties" fragment, I get this error on System.out/err:
java.lang.Exception: BMUnit : Unable to identify test JVM process during agent load
and this result in my unit tests:
java.lang.Exception: Unexpected exception, expected<java.lang.SecurityException> but was<java.net.ConnectException>
at org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:28)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:432)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:189)
at org.jboss.byteman.agent.submit.Submit$Comm.<init>(Submit.java:797)
at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:735)
at org.jboss.byteman.agent.submit.Submit.addScripts(Submit.java:574)
at org.jboss.byteman.agent.submit.Submit.addRulesFromFiles(Submit.java:547)
at org.jboss.byteman.contrib.bmunit.BMUnit.loadScriptFile(BMUnit.java:295)
at org.jboss.byteman.contrib.bmunit.BMUnitRunner$5.evaluate(BMUnitRunner.java:248)
at org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:21)
Any ideas what might be happening? Might it be the timing? For now I can keep the property in the pom.xml file, but it just seems odd. I can log an bug report if you think that's appropriate.