The rule looks fine to me and ought to just work (TM) so this looks very much like a problem with Byteman.
Can you try with the 2.1.4 release. I just fixed a problem which was causing verify errors and, although I suspect it is not the cause here, I would like to rule out any possibility of that being the error.
If that does not remove the error then I will see if I can reproduce the same result. Do you know if your app server isdoing anything special at transaction recovery time? e.g. loading dead transactions?
It would be a great help if you could provide me with a copy of the bytecode which is causing the verify error. Can you set the following system properties when you install the agent into JBoss eap
n.b. you will need to create directory $HOME/tmp/dump
If you are installing Byteman from the java command line using -javaagent then just add the above two defines to JAVA_OPTS. If you are using bminstall.sh then you can jsut add them to the command line in font of the process if argument.
When your rule gets processed a copy fo the transformed bytecode should be written to file $HOME/tmp/dump/com/.../XARecoveryModule.class. If you execute
$ javap -c -classpath $HOME/tmp/dump com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule > foo.txt
this will decompile the bytecode for the transformed class. If you can post the output in foo.txt which relates to method xaRecovery (or just send me a copy of the whole file) I will see if I can work out how it has been transformed incorrectly.
Thanks! I need to return to this, but don't have the cycles right now... so I appreciate the comments and I'll use them when I tackle it again.