Instrumentation based on Annotation?

[bluegol]

Hi,

(This is bad...) Is there a way for a rule to be triggered based on injection? (I'm expecting "No)

The problem: I'm trying to instrument EJB calls. It appears (I'm a java newbie) that EJB classes

can be identified by annotations of javax.ejb.*, and only by them. Is there a way to handle this

with byteman?

Jahwan

[adinn]

Hi Jahwan,

Well, ... no :-)

Ok, but this is an interesting question which merits two separate answers:

The generic answer is "Yes, this could be done by extending Byteman to support it but that would probably be the wrong way to go about doing what you want". The same question has come up under several different guises where a more general model for identifying the target class for rule injection is requested,-- the most frequent variation being "Can I haz a wildcard/regexp name in my CLASS/INTERFACE clause". Indeed there is an open JIRA (q.v.) for that latter request where the answer provided will probably also address your request.

As per that previous response, I recommend you to solve your problem offline rather than try to get Byteman to solve it slowly online. So, write a program which uses the Jar API to identify the classes you might be interested in instrumenting. Have that program load the classes from your jars one by one and use reflection to identify whether or not they have EJB annotations. Where they do you can get your program to write a rule specific to the class in question which can inject whatever behaviour you want. It can even use reflection to identify structural properties of the class and teak the generated rule accordingly. When Byteman loads the resulting script into your application it will be able to do a constant time lookup at every class load to decide whether or not there is a rule for the class being loaded.

Ok, what about the specific answer. The thing to bear in mind is that injecting code into classes annotated with EE annotations should only be attempted with good knowledge of what the EE container is going to do. That's because the EE server is itself very likely to be applying transformations to the classes bearing the annotations. How so? Well, since the EE container is in full control of the loading process it is able to completely alter the structure of those classes by rewriting the bytecode at load time. This may not be as simple as tweaking the method bytecode (which is all that Byteman does). The container may also make structural alterations like adding or removing fields and methods, changing supers or adding/removing interfaces. The container will normally apply these transformations before agents gets a chance to see the bytecode (it usually intercepts the standard class load between loading the bytecode and calling ClassLoader.defineClass -- by contrast, agent transformers are invoked from the VM underneath ClassLoader.defineClass). So, unless you have a good idea what the EE container is going to do you may find that your rules don't get injected or that the injection process leads to errors or unexpected outcomes. Of course, you can try it and see what happens but note also that your results may not be portable from one EE container to another or between releases i.e. you may be a hostage to fortune should you go down this path.

regards,

Andrew Dinn

[bluegol]

Hi Andrew,

(1) pre-analyzing jar file is a nice idea. Yes, I agree with you on NOT making byteman trigger more complicated (and slower).

I actually read your reply to a similar request before: [BYTEMAN-114] support wildcard matching - JBoss Issue Tracker

Oh well, that's the same as you linked.

(2) Yes, I need to be extremely careful with every step of injecting anything. Not that much, but injecting something into JDBC

with Spring and myBatis turned out way more complicated than I thought!

Thanks for your answer and suggestion. I need to give my problem some deep thoughts.

Best,

Jahwan

[adinn]

Hi Jahwan,

Glad to hear you were already up to speed on the answer when I replied :-). Please feel free to keep your questions coming. I'm always glad to have a keen, new user, especially one who asks the right questions.

regards,

Andrew Dinn