10 Replies Latest reply on Nov 30, 2011 11:31 AM by adinn

    @BMRule not applied when executing test with TestNG

    boky8

      Hi all.

       

      I've followed the suggestion at another thread and was able to get Byteman running with Maven. We use TestNG for our unit testing and applying Byteman was a breeze:

       

       

      import org.jboss.byteman.contrib.bmunit.BMNGRunner;
      import org.jboss.byteman.contrib.bmunit.BMRule;
      import org.testng.annotations.Test;
      
      
      import java.net.URI;
      import java.net.URISyntaxException;
      import java.util.regex.Pattern;
         
      /**
       * Test UUID generation, make sure no errors are thrown.
       */
      public class UUIDGeneratorTest extends BMNGRunner {
          @BMRule(
                  name = "Throw exception while constructing an URI",
                  targetClass = "java.net.URI",
                  targetMethod = "<init>(String)",
                  condition = "TRUE",
                  action = "throw new java.net.URISyntaxException(\"Bad bad URI!\")"
          )
          @Test(expectedExceptions = RuntimeException.class)
          void testURIException() {
              try {
                  URI u = new URI("http://www.google.com/");
              } catch (URISyntaxException e) {
                  throw new RuntimeException(e);
              }
          }
      }
      

       

       

      Now, when running "mvn test" I can see for a fact that Byteman is invoked:

       

       

      -------------------------------------------------------
       T E S T S
      -------------------------------------------------------
      Forking command line: cmd.exe /X /C 
         "C:\Progra~1\Java\jdk1.6.0_23\jre\bin\java -jar 
         ...\target\surefire\surefirebooter535310703746999409.jar 
         ...\target\surefire\surefire7511017580910689691tmp
          ...\target\surefire\surefire6151072117527255171tmp"
      Running UUIDGeneratorTest
      BMUNit : loading agent id = 11340
      byteman jar is C:\Users\Boky\.m2\repository\org\jboss\byteman\byteman\1.6.0\byteman-1.6.0.jar
      TransformListener() : accepting requests on localhost:9091
      BMUNit : loading text script = UUIDGeneratorTest+testURIException
      TransformListener() : handling connection on port 9091
      BMUNit : unloading text script = UIDGeneratorTest+testURIException
      TransformListener() : handling connection on port 9091
      Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.73 sec <<< FAILURE!
      

       

      So, script is loaded, but the rule does not apply. I have tried many variations including:

      • typing condition "TRUE" in lowercase (should make a difference and it didn't)
      • removing the condition completely
      • typing targetClass without the package prefix
      • changing targetMethod to "<init>", "java.net.URI(String)"...

       

      But it simply does not work. What am I doing wrong?

       

       

      Tnx,

      B

        • 1. Re: @BMRule not applied when executing test with TestNG
          adinn

          Hi B(oky)

           

          Thanks for posting this.

           

          boky8 wrote:

           

          . . .

           

          So, script is loaded, but the rule does not apply. I have tried many variations including:

          • typing condition "TRUE" in lowercase (should make a difference and it didn't)
          • removing the condition completely
          • typing targetClass without the package prefix
          • changing targetMethod to "<init>", "java.net.URI(String)"...

           

          But it simply does not work. What am I doing wrong?

          That's a very good question. It certainly looks as if you have set everything up correctly. It would help if you configured surefire to supply the following command line argument to the test JVM

           

          -Dorg.jboss.byteman.verbose

           

          This should show details of any inject, parse, typecheck and execute operations performed by the rule engine. If you can do this and post the resulting output I will be happy to help interpret it.

           

          regards,

           

           

          Andrew DInn

          • 2. Re: @BMRule not applied when executing test with TestNG
            boky8

            Yeah, but that's it.

             

            This is in my pom.xml:

             

                            <plugin>
                                <groupId>org.apache.maven.plugins</groupId>
                                <artifactId>maven-surefire-plugin</artifactId>
                                <version>2.10</version>
                                <configuration>
                                    <additionalClasspathElements>
                                        <additionalClasspathElement>${java.home}/lib/tools.jar</additionalClasspathElement>
                                    </additionalClasspathElements>
                                    <systemProperties>
                                        <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>
                                </configuration>
                            </plugin>
            
            

             

            And all that it prints is what I've sent you before. I'll try running with <value></value> and let you know about the results.

            • 3. Re: @BMRule not applied when executing test with TestNG
              boky8

              I rechecked and rechecked.The property is set and that is all I get from output is what I've specified above. You can see the property being set in line 10. If it weren't set the BMUnit debug would not be set either, I guess.

               

              This is a bit more logging. maven was run with mvn -X test:

               

              [INFO] Surefire report directory: C:\development\...\target\surefire-reports
              [DEBUG] dummy:dummy:jar:1.0 (selected for null)
              [DEBUG]   org.apache.maven.surefire:surefire-booter:jar:2.10:compile (selected for compile)
              [DEBUG]     org.apache.maven.surefire:surefire-api:jar:2.10:compile (selected for compile)
              [DEBUG] Adding to surefire booter test classpath: C:\...\.m2\repository\org\apache\maven\surefire\surefire-booter\2.10\surefire-booter-2.10.jar Scope: compile
              [DEBUG] Adding to surefire booter test classpath: C:\...\.m2\repository\org\apache\maven\surefire\surefire-api\2.10\surefire-api-2.10.jar Scope: compile
              [DEBUG] Setting system property [org.jboss.byteman.contrib.bmunit.verbose]=[true]
              [DEBUG] Setting system property [user.dir]=[C:\development\projects\PIXPDQESB\hl7-schemas]
              [DEBUG] Setting system property [localRepository]=[C:\...\.m2\repository]
              [DEBUG] Setting system property [org.jboss.byteman.verbose]=[true]
              [DEBUG] Setting system property [basedir]=[C:\development\projects\PIXPDQESB\hl7-schemas]
              [DEBUG] Using JVM: C:\Progra~1\Java\jdk1.6.0_23\jre\bin\java
              [DEBUG] dummy:dummy:jar:1.0 (selected for null)
              [DEBUG]   org.apache.maven.surefire:surefire-testng:jar:2.10:test (selected for test)
              [DEBUG]     org.apache.maven:maven-artifact:jar:2.0:test (selected for test)
              [DEBUG]       org.codehaus.plexus:plexus-utils:jar:1.0.4:test (selected for test)
              [DEBUG]     org.apache.maven.surefire:surefire-testng-utils:jar:2.10:test (selected for test)
              [DEBUG]       org.testng:testng:jar:jdk15:5.7:test (selected for test)
              [DEBUG]         junit:junit:jar:3.8.1:test (selected for test)
              [DEBUG]       org.apache.maven.surefire:surefire-api:jar:2.10:test (selected for test)
              [DEBUG]     org.testng:testng:jar:jdk15:5.7:test (selected for test)
              [DEBUG]       junit:junit:jar:3.8.1:test (selected for test)
              [DEBUG]     org.apache.maven.surefire:surefire-api:jar:2.10:test (selected for test)
              [DEBUG] Adding to surefire test classpath: C:\...\.m2\repository\org\apache\maven\surefire\surefire-testng\2.10\surefire-testng-2.10.jar Scope: test
              [DEBUG] Adding to surefire test classpath: C:\...\.m2\repository\org\apache\maven\maven-artifact\2.0\maven-artifact-2.0.jar Scope: test
              [DEBUG] Adding to surefire test classpath: C:\...\.m2\repository\org\codehaus\plexus\plexus-utils\1.0.4\plexus-utils-1.0.4.jar Scope: test
              [DEBUG] Adding to surefire test classpath: C:\...\.m2\repository\org\apache\maven\surefire\surefire-testng-utils\2.10\surefire-testng-utils-2.10.jar Scope: test
              [DEBUG] Adding to surefire test classpath: C:\...\.m2\repository\org\apache\maven\surefire\surefire-api\2.10\surefire-api-2.10.jar Scope: test
              [DEBUG] test classpath classpath:
              [DEBUG]   C:\...\target\test-classes
              [DEBUG]   C:\...\target\classes
              [DEBUG]   C:\...\.m2\repository\com\sun\xml\bind\jaxb-impl\2.2.4-1\jaxb-impl-2.2.4-1.jar
              [DEBUG]   C:\...\.m2\repository\javax\xml\bind\jaxb-api\2.1\jaxb-api-2.1.jar
              [DEBUG]   C:\...\.m2\repository\javax\xml\stream\stax-api\1.0-2\stax-api-1.0-2.jar
              [DEBUG]   C:\...\.m2\repository\javax\activation\activation\1.1\activation-1.1.jar
              [DEBUG]   C:\...\.m2\repository\jug\jug\1.1.2\jug-1.1.2.jar
              [DEBUG]   C:\...\.m2\repository\org\codehaus\groovy\groovy-all\1.8.4\groovy-all-1.8.4.jar
              [DEBUG]   C:\...\.m2\repository\commons-lang\commons-lang\2.6\commons-lang-2.6.jar
              [DEBUG]   C:\...\.m2\repository\org\slf4j\slf4j-api\1.6.3\slf4j-api-1.6.3.jar
              [DEBUG]   C:\...\.m2\repository\org\slf4j\jcl-over-slf4j\1.6.3\jcl-over-slf4j-1.6.3.jar
              [DEBUG]   C:\...\.m2\repository\org\slf4j\slf4j-jdk14\1.6.3\slf4j-jdk14-1.6.3.jar
              [DEBUG]   C:\...\.m2\repository\xmlunit\xmlunit\1.3\xmlunit-1.3.jar
              [DEBUG]   C:\...\.m2\repository\org\testng\testng\6.2.1\testng-6.2.1.jar
              [DEBUG]   C:\...\.m2\repository\junit\junit\4.5\junit-4.5.jar
              [DEBUG]   C:\...\.m2\repository\org\beanshell\bsh\2.0b4\bsh-2.0b4.jar
              [DEBUG]   C:\...\.m2\repository\com\beust\jcommander\1.12\jcommander-1.12.jar
              [DEBUG]   C:\...\.m2\repository\org\yaml\snakeyaml\1.6\snakeyaml-1.6.jar
              [DEBUG]   C:\...\.m2\repository\org\jboss\byteman\byteman\1.6.0\byteman-1.6.0.jar
              [DEBUG]   C:\...\.m2\repository\org\jboss\byteman\byteman-install\1.6.0\byteman-install-1.6.0.jar
              [DEBUG]   C:\Progra~1\Java\jdk1.6.0_23\jre\..\lib\tools.jar
              [DEBUG]   C:\...\.m2\repository\org\jboss\byteman\byteman-submit\1.6.0\byteman-submit-1.6.0.jar
              [DEBUG]   C:\...\.m2\repository\org\jboss\byteman\byteman-bmunit\1.6.0\byteman-bmunit-1.6.0.jar
              [DEBUG]   C:\Progra~1\Java\jdk1.6.0_23/lib/tools.jar
              [DEBUG]   C:\...\.m2\repository\org\apache\maven\surefire\surefire-testng-utils\2.10\surefire-testng-utils-2.10.jar
              [DEBUG] provider classpath classpath:
              [DEBUG]   C:\...\.m2\repository\org\apache\maven\surefire\surefire-testng\2.10\surefire-testng-2.10.jar
              [DEBUG]   C:\...\.m2\repository\org\apache\maven\maven-artifact\2.0\maven-artifact-2.0.jar
              [DEBUG]   C:\...\.m2\repository\org\codehaus\plexus\plexus-utils\1.0.4\plexus-utils-1.0.4.jar
              [DEBUG]   C:\...\.m2\repository\org\apache\maven\surefire\surefire-testng-utils\2.10\surefire-testng-utils-2.10.jar
              [DEBUG]   C:\...\.m2\repository\org\apache\maven\surefire\surefire-api\2.10\surefire-api-2.10.jar
              
              
              -------------------------------------------------------
               T E S T S
              -------------------------------------------------------
              Forking command line: cmd.exe /X /C "C:\Progra~1\Java\jdk1.6.0_23\jre\bin\java -jar 
                 C:\...\target\surefire\surefirebooter1934786793627164890.jar 
                 C:\...\target\surefire\surefire6865071547569861974tmp 
                 C:\...\target\surefire\surefire8889621209312100973tmp"
              Running UUIDGeneratorTest
              23.11.2011 20:55:22 UUIDGenerator getLocalAddress
              INFO: MAC address for this server is: 00:ff:8f:82:a2:3b. This will be used for time-based UUID generation.
              BMUNit : loading agent id = 14232
              byteman jar is C:\...\.m2\repository\org\jboss\byteman\byteman\1.6.0\byteman-1.6.0.jar
              TransformListener() : accepting requests on localhost:9091
              BMUNit : loading text script = UUIDGeneratorTest+testURIException
              TransformListener() : handling connection on port 9091
              BMUNit : unloading text script = UUIDGeneratorTest+testURIException
              TransformListener() : handling connection on port 9091
              Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.11 sec <<< FAILURE!
              
              
              Results :
              
              
              Failed tests:   testURIException(com.parsek.ehealth.hl7.data.UUIDGeneratorTest):
              
              

               

              Exacly the same thing happens when running the tests directly from the command line:

               

              C:\development\...>java -Dorg.jboss.byteman.verbose -Dorg.jboss.byteman.contrib.bmunit.verbose org.testng.TestNG -verbose 2 -testclass UUIDGeneratorTest
              [TestNG] Running:
                Command line suite
              
              
              23.11.2011 21:16:32 UUIDGenerator getLocalAddress
              INFO: MAC address for this server is: 00:ff:8f:82:a2:3b. This will be used for time-based UUID generation.
              BMUNit : loading agent id = 11708
              byteman jar is C:\...\.m2\repository\org\jboss\byteman\byteman\1.6.0\byteman-1.6.0.jar
              TransformListener() : accepting requests on localhost:9091
              BMUNit : loading text script = UUIDGeneratorTest+testURIException
              TransformListener() : handling connection on port 9091
              BMUNit : unloading text script = UUIDGeneratorTest+testURIException
              TransformListener() : handling connection on port 9091
              PASSED: testNewRandomBasedUuid
              PASSED: testNewRandomBasedUuidAsURI
              PASSED: testNewTimeBasedUuid
              PASSED: testNewTimeBasedUuidAsURI
              FAILED: testURIException
              org.testng.TestException:
              Expected exception java.lang.RuntimeException but got org.testng.TestException:
              Method UUIDGeneratorTest.testURIException()[pri:0, instance:UUIDGeneratorTest@4e99353f] should have thrown an exception of class java.lang.RuntimeException
                      at org.testng.internal.Invoker.handleInvocationResults(Invoker.java:1459)
                      at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1222)
                      at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
                      at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
                      at org.testng.TestRunner.privateRun(TestRunner.java:753)
                      at org.testng.TestRunner.run(TestRunner.java:613)
                      at org.testng.SuiteRunner.runTest(SuiteRunner.java:335)
                      at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:330)
                      at org.testng.SuiteRunner.privateRun(SuiteRunner.java:292)
                      at org.testng.SuiteRunner.run(SuiteRunner.java:241)
                      at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
                      at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
                      at org.testng.TestNG.runSuitesSequentially(TestNG.java:1169)
                      at org.testng.TestNG.runSuitesLocally(TestNG.java:1094)
                      at org.testng.TestNG.run(TestNG.java:1006)
                      at org.testng.TestNG.privateMain(TestNG.java:1316)
                      at org.testng.TestNG.main(TestNG.java:1280)
              Caused by: org.testng.TestException:
              Method UUIDGeneratorTest.testURIException()[pri:0, instance:UUIDGeneratorTest@4e99353f] should have thrown an exception of class java.lang.RuntimeException
                      at org.testng.internal.Invoker.handleInvocationResults(Invoker.java:1485)
                      at org.testng.internal.Invoker.invokeMethod(Invoker.java:740)
                      at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:883)
                      at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1208)
                      ... 15 more
              
              
              
              
              ===============================================
                  Command line test
                  Tests run: 5, Failures: 1, Skips: 0
              ===============================================
              
              
              
              
              ===============================================
              Command line suite
              Total tests run: 5, Failures: 1, Skips: 0
              ===============================================
              
              
              [TestNG] Time taken by org.testng.reporters.EmailableReporter@3d434234: 6 ms
              [TestNG] Time taken by org.testng.reporters.SuiteHTMLReporter@60072ffb: 28 ms
              [TestNG] Time taken by org.testng.reporters.JUnitReportReporter@67006d75: 4 ms
              [TestNG] Time taken by [TestListenerAdapter] Passed:0 Failed:0 Skipped:0]: 6 ms
              [TestNG] Time taken by org.testng.reporters.XMLReporter@3148aa23: 18 ms
              
              

               

               

              I can also try other versions and downloading byteman directly. Other than I'm out of ideas.

              • 4. Re: @BMRule not applied when executing test with TestNG
                adinn

                Hi Boky,

                 

                Looking at the trace output I can see that the verbose flags are taking effect. For example, the line

                 

                TransformListener() : accepting requests on localhost:9091

                 

                is only printed by the agent listener when verbose tracing is on -- here is the corresponding source code in class TransformListener

                 

                if (Transformer.isVerbose()) {

                    System.out.println("TransformListener() : accepting requests on " + hostname + ":" + port);

                }

                 

                The same applies for the messages preceded with prefix "BMUnit : ". These messages only get printed if org.jboss.byteman.contrib.bmunit.verbose is defined.

                 

                So, it looks like the rules are being uploaded. You can see that from the messages

                 

                BMUNit : loading text script = . . .

                TransformListener() : handling connection on port 9091

                 

                Similarly, a connection is  being made to unload the rules.

                 

                So, if the rule was uploaded then there are two possibilities. If class URI is already loaded then the agent should find it in the loaded class list and schedule a retransform. This would be accompanied by a message saying retransforming java.net.URI. This suggests it is not yet loaded. So, when the test contnues and it is loaded the bytecode should be passed to the agent before any methods get run. In this case you should see verbose printout identifying that the rule had been injected into the target method. If there was a parse or type error then you should see this instead. I don't really understand how either of these options can fail to happen. The rule is added to the agent's list of in-memory classes before the list of loaded classes is checked. So, even if the class gets loaded just before the agent checks the list the rule should still be found and injected.

                 

                There might possibly be a small timing window where class URI gets loaded before the rule is installed but only gets added to the list after the agent has checked it. The VM does not really provide any clean guarantees regarding timing of agent operations. However, that seems to me to be unlikely and almost certainly not something which would happen in just this one case but not in others.

                 

                Ok, so where can we go from here:

                 

                Have you been able to get Byteman to run under maven using any other tests? Perhaps you could try that?

                 

                You could also modify this broken test so that it does not refer to URI directly,-- instead calling a method of an auxiliary class which imports URI. That might show whether this is a load+timing issue.

                 

                Also, could you try loading the same rule from a script using the BMScript annotation? That might indicate whether something is going wrong converting the annotation text to a rule.

                 

                Have you been able to use Byteman when you run code using the java command line? If so then this might indicate that it is a maven issue rather than a JVM issue (although I don't really know what that could be). If not then it might be something to do with your JVM/JDK configuration.

                 

                Apologies for not being  able to simply point to the problem here but it is not something I have seen before and it doesn't make much sense to me at present.

                • 5. Re: @BMRule not applied when executing test with TestNG
                  boky8

                  Andrew,

                   

                  thank you so much for your feedback. I will try to create isolated tests and see what works. I will attach these tests for you and you can include them in Byteman CI cycle, if we find the problem.

                   

                  Thanks for the elaborative answer.

                  • 6. Re: @BMRule not applied when executing test with TestNG
                    adinn

                    Hi Boky

                    boky8 wrote:

                     

                    Andrew,

                     

                    thank you so much for your feedback. I will try to create isolated tests and see what works. I will attach these tests for you and you can include them in Byteman CI cycle, if we find the problem.

                     

                    Thanks for the elaborative answer.

                    You are welcome and, indeed, thank you for persevering with this problem and helping me to improve Byteman.

                    • 7. Re: @BMRule not applied when executing test with TestNG
                      boky8

                      I'm attaching a byteman-test maven problem that has been stripped to the bone and exibits the noted problem. It does not matter if you use @BMRule or @BMScript - the problem persists.

                       

                      I've even turned on java trace class loading and java.net.URI is loaded before Byteman. Let me know if there's anything else I can do.

                       

                       

                      Cheers,

                      B

                      • 8. Re: @BMRule not applied when executing test with TestNG
                        adinn

                        Hi Boky,

                         

                        Apologies for the delayed response. You were shelved temporarily but not forgotten. ANyway, I now have a complete answer as to what is going on with a few very interesting wrinkles :-)

                         

                        Ok, so first thing is that I found the reason why the rule was not being loaded. The problem is in class ScriptRepository which maintains the internal database of loaded rules. The problem arises in method matchTarget when trying to check whether a newly installed method applies to an already loaded class:

                         

                        private boolean matchTarget(String name, Class<?> clazz, boolean isInterface, boolean isOverride) {

                            Map<String, List<RuleScript>> index = (isInterface ? targetInterfaceIndex : targetClassIndex);

                            synchronized (index) {

                                List<RuleScript> ruleScripts = index.get(name);

                                if (ruleScripts != null) {

                                    for (RuleScript ruleScript: ruleScripts) {

                                        if (isOverride && !ruleScript.isOverride()) {

                                            continue;

                                        }

                                        String methodName = ruleScript.getTargetMethod();

                                        int signaturePos = methodName.indexOf("(");

                                        if (signaturePos > 0) {

                                            methodName = methodName.substring(0, signaturePos).trim();

                                        }

                                        if (methodName == "<init>" || methodName == "<clinit>") {

                                            // every class has some sort of constructor so accept it

                                            return true;

                                        }

                                        . . .

                         

                        You have probably spotted the error . . . that comparison against "<init>" or "<clinit>" uses == when it ought to use .equals().

                         

                        What amazes me is that this has not shown up before but it is entirely possible that the == comparison might work in some cases but not others.

                         

                        I have raised a JIRA for this which will be fixed in Byteman 2.0.0

                         

                        https://issues.jboss.org/browse/BYTEMAN-181

                         

                        So, next I ran your test with the == replaced by .equals expecting it to work.However, I found that there are a couple of other problems.

                         

                        Fisrtly, you rules need to supply two Strings as arguments in the throw new URISyntaxException() expression. The class does not have a constructor taking one String. So, for example, your script rule should have the following DO clause

                         

                        DO throw new java.net.URISyntaxException($1, "bad bad URI!")

                         

                        Same applies for the inline code in the BMRule annotations.

                         

                        The relevant  constructor is declared as follows

                         

                        public URISyntaxException(String input, String reason);

                         

                        The first argument should be the URL supplied as argument to the URL constructor, $1.

                         

                        I applied that fix to all the inline rules and scripts and then ran into the next problem which is . . . interesting. Essentially, your rule has broken all URI creation. Thta's a fairly dangerousthing to inject into the JVM and, in fact, it causes a problemfor Byteman itself. When the test finishes the Byteman test runner code tries to open a socket to the agent listener in order to ask it to unload the rule. This fails because somewhere below the call to Socket.<init> the implementation tries to create a URL --  auto-snookered!

                         

                        A fix would be to add a condition like the following to your rules

                         

                        RULE throw URI construction exception

                            CLASS java.net.URI

                            METHOD <init>(String)

                            AT ENTRY

                            IF callerMatches("Simple.*",  true)

                            DO throw new java.net.URISyntaxException("bad bad URI!")

                        ENDRULE

                         

                        The built-in callerMatches can be used to ensure that there is a frame in the call stack with a method name taht matches the specifiedregular expression. There are many overloaded versions of this method. If you just pass the regular expression argument it looks at the direct caller frame and the bare method name. If you add a second argument 'true' it includes the class name when doing the match.Another 'true' means include the package name. You canalso provide a frame count or a start frame and frame count. Anyway, this version says ony trigger the rule if the class qualified method name of the immediate caller starts wirth prefix Simple. This means an exception will be thrown from your app class Simple and from your test methods in classes SimpleTest and SimplePreloadTest but they wil not be thrown from any other classes. I modifedthe ruels accordingly and the test run successfully tocompletion. For example, here is the BMRule annotation for one of the test classes

                         

                        @BMRule(

                            name = "throw URI exception",

                            targetClass = "java.net.URI",

                            targetMethod = "<init>(String)",

                            condition= "callerMatches(\"Simple.*\",  true)",

                            action = "throw new java.net.URISyntaxException($1, \"bad bad URI!\")"

                        )

                        @Test(expectedExceptions = URISyntaxException.class)

                        public void testDirectBMRuleOKURI() throws URISyntaxException {

                            new java.net.URI("http://www.google.com/");

                        }

                         

                        Finally, there is one other thing you might want to add to your pom. If environment variable BYTEMAN_HOME is set then the BMUnit package uses this to locate the agent jar (byteman.jar) rather than finding it in the classpath. This is probably the wrong way round i.e. it shoudl be found first via the classpath and then, failing that, via BYTEMAN_HOME. I will correct this in the 2.0.0 release. Until then it is a good idea to set this variable to an empty string in the surefire config.

                         

                        <environmentVariables>

                            <property>

                                <name>BYTEMAN_HOME</name>

                                <value></value>

                            </property>

                        </environmentVariables>

                        1 of 1 people found this helpful
                        • 9. Re: @BMRule not applied when executing test with TestNG
                          boky8

                          Hey,

                           

                          thanks a lot for this. Also glad I could help improve Byteman.

                           

                          I'll wait for the new Byteman release and implement everything as you've stated. Looking forward to it. Will let you know how it goes.

                          • 10. Re: @BMRule not applied when executing test with TestNG
                            adinn

                            Hi Boky,

                            boky8 wrote:

                             

                            thanks a lot for this. Also glad I could help improve Byteman.

                             

                            I'll wait for the new Byteman release and implement everything as you've stated. Looking forward to it. Will let you know how it goes.

                             

                            Thank you for your patience and perseverance. I also am very glad you could help improve Byteman. Community works!