I haven't experimented yet with EMMA (about to do so) but you explain everywhere why it is impossible to do instrumentation under J2EE servers due to class loading issues.
Well, take a look at AspecWerkz project - they do that to about every J2EE server out there (BEA, JBoss, WebSphere, etc.).
Worth taking their instrumentation framework (I think it is available in the code as a standalone)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is no *standard* J2EE way of doing instrumentation.
BEA and JBoss have *proprietary* class manipulation APIs.
And as far as WebSphere goes, AspectWerkz supports online mode by *hacking bootstrap classes*.
I am not about to go down this difficult path of supporting individual J2EE servers via such one-off solutions.
To quote AspectWerks's own FAQ, "AspectWerkz supports all java environment thru offline mode." And so does EMMA: its offline mode works for any JVM, any J2EE server. So, what's your point?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Vlad,
I agree that it would be impossible to support all of the individual J2EE servers using methods specific to each server. What about going the other way?
Does the architecture of EMMA allow you to provide an interface that you could publish that would allow an app server to pass control to EMMA? Maybe something on the line of a decorator pattern.
Michael.Giroux@objectweb.org
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
BTW, are we talking about dynamic mode, or instrumented mode (instrument/run/report)?
I'm using the ObjectWeb JOnAS app server from jonas.objectweb.org. I've been told that a tool named "clover" works with JOnAS, so maybe EMMA will also.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Clover is a tool that works by instrumenting your Java *source* code (.java files). Because of that, it has to be run during your build, as a compiler extension of sorts. Obviously, no dynamic bytecode instrumentation can happen here.
EMMA works by instrumenting your Java *bytecode* (.class files). It can be used during the build, as a second compiler of sorts (in which case it can be used for any Java runtime regardless of which J2EE server it runs) OR on-the-fly. The latter is only feasible for simple runtimes, the ones that don't do their own classloading. This is because (a) there is no standard way to intercept classloading in a generic J2SE runtime and (b) there is no protocol for classloader cooperation of any kind.
The differences between Clover and EMMA need to be kept in mind when comparing the two. There are many technical ways to obtain code coverage (JVMPI, JVMDI, source instrumentation, bytecode instrumentation) and they are not equal with respect to what they can do and in which contexts they apply.
The bottom line is, if you can afford to prepare your classes for coverage during the build using Clover, I don't see why you couldn't do the same with EMMA. It's as simple as that: compile/instrument/deploy/run/get coverage.
EMMA's current philosophy is explained in the FAQ (http://emma.sourceforge.net/faq.html). Specifically, the entry titled "How do I use EMMA in {WebLogic, Websphere, Tomcat, JBoss, etc}?" provides instructions for getting coverage in J2EE environment.
I *know* this works because at Trilogy (where I work) EMMA has been used successfully with Tomcat, Websphere, and WebLogic. I didn't go public on SourceForge until *after* I had some good beta testing completed.
I know it has worked for a number of external EMMA users as well.
Yes, EMMA could be enhanced in ways that make this J2EE stuff easier. It might happen one day. For now, you have to agree with me that since the offline instrumentation is a generically applicable solution, it would be unwise for me to invest so much time in proprietary runtime support (the value/effort ratio is just too low).
If you like EMMA and would like to see more ehancements, consider joining the project as a contributor.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I haven't experimented yet with EMMA (about to do so) but you explain everywhere why it is impossible to do instrumentation under J2EE servers due to class loading issues.
Well, take a look at AspecWerkz project - they do that to about every J2EE server out there (BEA, JBoss, WebSphere, etc.).
Worth taking their instrumentation framework (I think it is available in the code as a standalone)
There is no *standard* J2EE way of doing instrumentation.
BEA and JBoss have *proprietary* class manipulation APIs.
And as far as WebSphere goes, AspectWerkz supports online mode by *hacking bootstrap classes*.
I am not about to go down this difficult path of supporting individual J2EE servers via such one-off solutions.
To quote AspectWerks's own FAQ, "AspectWerkz supports all java environment thru offline mode." And so does EMMA: its offline mode works for any JVM, any J2EE server. So, what's your point?
Vlad,
I agree that it would be impossible to support all of the individual J2EE servers using methods specific to each server. What about going the other way?
Does the architecture of EMMA allow you to provide an interface that you could publish that would allow an app server to pass control to EMMA? Maybe something on the line of a decorator pattern.
Michael.Giroux@objectweb.org
BTW, are we talking about dynamic mode, or instrumented mode (instrument/run/report)?
I'm using the ObjectWeb JOnAS app server from jonas.objectweb.org. I've been told that a tool named "clover" works with JOnAS, so maybe EMMA will also.
Clover is a tool that works by instrumenting your Java *source* code (.java files). Because of that, it has to be run during your build, as a compiler extension of sorts. Obviously, no dynamic bytecode instrumentation can happen here.
EMMA works by instrumenting your Java *bytecode* (.class files). It can be used during the build, as a second compiler of sorts (in which case it can be used for any Java runtime regardless of which J2EE server it runs) OR on-the-fly. The latter is only feasible for simple runtimes, the ones that don't do their own classloading. This is because (a) there is no standard way to intercept classloading in a generic J2SE runtime and (b) there is no protocol for classloader cooperation of any kind.
The differences between Clover and EMMA need to be kept in mind when comparing the two. There are many technical ways to obtain code coverage (JVMPI, JVMDI, source instrumentation, bytecode instrumentation) and they are not equal with respect to what they can do and in which contexts they apply.
The bottom line is, if you can afford to prepare your classes for coverage during the build using Clover, I don't see why you couldn't do the same with EMMA. It's as simple as that: compile/instrument/deploy/run/get coverage.
EMMA's current philosophy is explained in the FAQ (http://emma.sourceforge.net/faq.html). Specifically, the entry titled "How do I use EMMA in {WebLogic, Websphere, Tomcat, JBoss, etc}?" provides instructions for getting coverage in J2EE environment.
I *know* this works because at Trilogy (where I work) EMMA has been used successfully with Tomcat, Websphere, and WebLogic. I didn't go public on SourceForge until *after* I had some good beta testing completed.
I know it has worked for a number of external EMMA users as well.
Yes, EMMA could be enhanced in ways that make this J2EE stuff easier. It might happen one day. For now, you have to agree with me that since the offline instrumentation is a generically applicable solution, it would be unwise for me to invest so much time in proprietary runtime support (the value/effort ratio is just too low).
If you like EMMA and would like to see more ehancements, consider joining the project as a contributor.
Thanks for the complete explanation. I was confused by your reply to the original post.
"I am not about to go down this difficult path of supporting individual J2EE servers via such one-off solutions.
"
From this I concluded that EMMA does not work within J2EE, but the FAQ suggests using offline mode. Sorry about the confusion.