-
1. Re: $@ help.
adinn Jan 14, 2014 5:53 AM (in response to jolee)Hi Jonathon,
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?
-
2. Re: $@ help.
adinn Jan 14, 2014 6:13 AM (in response to adinn)Hi Johnathon,
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
-Dorg.jboss.byteman.dump.generated.classes
-Dorg.jboss.byteman.dump.generated.classes.directory=$HOME/tmp/dump
-Dorg.jboss.byteman.verbose
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.
-
3. Re: $@ help.
jolee Jan 20, 2014 3:15 PM (in response to jolee)Andrew,
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.
JLee