Thank you for trying Byteman.
Antonia Conti wrote:
I'm studying how to use Byteman recently but have some problems,
1 how to use EXCEPTION if it's define by user class, but not the class specified by Lable CLASS?
That may not be possible with Byteman as it is currently implemented. I have been considering this issue and I think I may be able to implement a mechanism to allow rules to import classes they wish to reference. However, at present the rule compiler typechecks and links rule code using the classloader context of the target class/interface specified by the CLASS or INTERFACE keyword.
So, for example, assume you have a rule like this
DO THROW new MyException
Let L1 be the classloader of the target class, SomeClass and L2 the loader of the referenced class, MyException. The typechecker uses L1 to resolve all type references from the rule code. So, with a conventional JVM class organization this rule will only typecheck if L2 == L1 or L2 is a direct or indirect parent of L1 (i.e. L1 <= L2 in the ordering implied by the parent relationship).
Ok, since this is a public forum here is some extra nitty-gritty detail for anyone interested in the full story. You can skip this if the answer above was all you wanted to know.
There are two other restrictions which also apply. Firstly, (a specific subset of) the Byteman classes must be visible from L1. That is why you have to install the byteman jar into the bootstrap classpath when you inject code into JVM classes like Thread (i.e. when L1 is the bootstrap loader then Byteman classes must be loaded via L1).
Secondly, if you use a HELPER class in your rule then it also must be visible from L1. Normally puttingyour helper jar in the (system) CLASSPATH is all you need to achieve this but,onceagain, when injecting into JVM classes the helper jar needsto be inserted into the bootstrap classpath.
Finally, I'll mention that when you use Byteman with OSGi or with, say, the JBoss Modules classloader (e.g. when using JBoss AS7) then the same ordering dependency L1 <= L2 must be satisfied but in this case the ordering is determined by the module inclusion relationship and it is a partial order rather than a full order. Now, most modules don't include org.jboss.byteman* which means that without taking some action to remedy things injected code breaks because it cannot find the Byteman classes. We fixed this in JBoss AS7 by configuring the module system so that any class in the byteman packages is automatically imported by all module classloaders (class lookups with this package prefix are automatically delegated upwards to parent loaders until they hit the system/bootstrap loader).
Right that's enough small print. Next question:
Antonia Conti wrote:
2 could final class be specified by Label CLASS? Since when i try to use it, the rule has no effect. But no error when checking by bmcheck.
Hmm, good question. The answer ought to be yes because program bmcheck actually injects the rule code into a class and type checks using exactly the same code as is executed by the Byteman agent. So, if bmcheck manages to inject the rule into your target class then the agent shoudl also be able to do it. If you don't see your rule executing it might be that the rule is getting injected but the trigger method is not getting called or the conditionisnot satisfied.
If you want to see whether your rule is being considered for injection I suggest you set system property -Dorg.jboss.byteman.verbose when you run your program/install the agent. You can set this property on the java command line alongside the -javaagent option. Alternatively, if you are using bminstall to load the agent dynamically you can pass it as an argument to bminstall, preceding the process id/appmain argument. You will see lots of trace showing what the agent is up to and this should include stuff about injecting and, possibly, executing rule code which mentions your rule by name.
If this trace does not clarify what is happening then please post details of your code or, at least, an example which fails to dowhat you expect. I will be happy to try to identify the problem.