HI Simon,

Thanks for reporting this problem.

Can I assume this is a JDK7 release of Java you are using? Could you please let me know the precise details (for example, the output of java -version woudl be perfect).

The verify error indicates that the JVM does not like the format of the code handed back to the VM after transformation. So, it suggests that either the Byteman transformer or, possibly, an EJB-specific transformer are making some incorrect assumptions about what is correct bytecode. Alternatively, they might both be making valid assumptions in isolation but breaking the code when acting in combination.

In general, injection of Byteman rules into EJBs can be a little tricky because the target class may not actually be what it appears to be. The EJB implementation has to modify an EJB in order to make it capable of interacting with/being driven by an EJB container. So, when you specify a location where you want Byteman to inject the code (using the CLASS METHOD and AT clauses) that location may have shifted or may not contain the same local variables as in the original code or may include synthetic code generated by the EJB implementation. Conversely, if the Byteman transformer gets to modify the rule first it may introduce code which confuses the EJB implementation (I think that is less likely though, given what Byteman does).

In order to help diagnose the problem I will probably need to see the bytecode of the EJB after it has been transformed by Byteman. Could you rerun your test wtih the following aditional java command line arguments

  -Dorg.jboss/.byteman.dump.generated.classes -Dorg.jboss.dump.generated.classes.directory=/path/to/my/dumpdir

Obviously, you need to replace the path component with a path to an actual directory -- you can use a relative path if you want but the directory must exist.

When you run the test Byteman should dump the transformed bytecode to

.../dumpdir/com/test/MySessionBean.class

You can either post me a zip with the clas file or else execute

  javap -c -private -classpath .../dumpdir com/test/MySessionBean

and post me the output. If you can also post me the original source that would help. Obviously, if this code is confidential then please try to find another example which reproduces the problem and avoids releasing any confidential details.

Hi Simon,

Looking at the bytecode I don't see any reason why it should result in a a verify error. The main part of the injected code is at bytecodes 0 to 6 which calls out to the rule engine. This is all just boiler plate code. At bytecodes 31 - 42 is the handler code which deals with the exceptions Byteman allows to escape the injection block. Bytecodes 31-36 handle an EarlyReturnException which Byteman uses to implement RETURN. It unpacks the embedded return value, ensures it is a String and then returns it. Bytecode 38-41 handles a ThrowException which Byteman uses to implement THROW. It unpacks the embedded Throwable and throws it. Bytecode 42 just rethrows an ExecuteException. All of this is correctly typed as far as I can see.

It looks to me like this problem relates to some interaction between Byteman's transformation and whatever transformations the EJB code makes to the class. Clearly, with this example the code is unmodified by any EJB transform at the point when Byteman sees it so it looks like the changes Byteman has made invaldiate some assumptions about the layout of the bytecode that the EJB code depends upon. I don't really know what that might be though. You might try posting a message on the EJB forum asking for nay input on this case. Of course, the answer might just be don't inject dircetly into an EJB because it doesn't work (or maybe just doesn't always work). I'll be very happy to advise the EJB team on whatever aspects of the problem relate to Byteman is doing but I cannot debug this any further without some input from them.

regards,

Andrew Dinn