When running Emma with a JEE container, the source .class files (not the .java files) are first instrumented and then deployed on the J2EE server.
Then the test classes are executed from ant command line or via an Eclipse plug-in, and this will write out the coverage data into .em or .ec files.
Sometimes, an error observed when running Emma is
emma.report:
[report] processing input files ...
[report] 2 file(s) read and merged in 172 ms
[report] com.vladium.emma.EMMARuntimeException: [CLASS_STAMP_MISMATCH] runtime version of class [com.xyz.action.MyAction] in the coverage data is not consistent with the version of this class in the metadata, possibly because stale metadata is being used for report generation.
[report] at com.vladium.emma.report.ReportDataModel.getView(ReportDataModel.java:95)
[report] at com.vladium.emma.report.AbstractReportGenerator.initialize(AbstractReportGenerator.java:207)
[report] at com.vladium.emma.report.html.ReportGenerator.process(ReportGenerator.java:85)
[report] at com.vladium.emma.report.ReportProcessor._run(ReportProcessor.java:254)
To calculate the coverage, EMMA combines data of two types:
metadata (static info about your Java classes, methods, lines, and basic blocks) and runtime coverage data (which basic blocks have been executed)
The error occurs when there is a mismatch in the versions of the classes used while recording the metadata.em and coverage.em files. The runtime version of the class in the coverage data is not consistent with the same class in the metadata
In simpler terms, the in-container application jars deployed on the JEE server are not in sync with the currently instrumented source from where the emma is being run, hence the class stamp difference in .emma files – metadata.em and coverage.em
Update -
A couple of comments posted below have some more checks and solutions to this problem.
I'm experiencing the same problem in a large scale application. I'm quite sure I'm using the correct em/ec files but I'm still getting this error, almost always, but from different classes
ReplyDeleteCurrently i made a quick patch to Emma runtime to just give me a warning in such situations, but I'd really appreciate sharing thoughts about this.
Bbossola,
ReplyDeleteOther things we checked for:
One of the dependent jars in WEB-INf/lib was older (the properties file building the classpath pointed to a wrong file) - it contained a version of a dependent class which was not in sync with the one actually needed for the class at emma runtime.
Seems similar issue can be faced with a dependent class found in a WEB-INF/lib jar but with a different package name.
If you are getting the failure on different classes, it could be a common dependency perhaps having version mismatches.
Lastly, a clue from this URL http://face.cs.drexel.edu/pipermail/cs576/2008-August/000193.html
execute the java command by hand (java -cp
../lib/emma.jar emma report -r txt -in metadata.emma,coverage.ec, ...)
or change the script to only include coverage files that I know I want
Emma was bombing out for me with the same error when i was trying to get a unified report for a number of projects. In my case it was because there were 2 projects where one was an improved version of the other, but with most of classes without any changes in the same packages. Emma successfully produced a unified report after i had excluded one of the copies.
ReplyDeleteAll the best,
Ruslan
Hi All,
ReplyDeletePlease help me out to get rid of this problem...
Using EMMA I have instrumented the .jar file (build) manually. Now whenever I trigger the following command to generate the code coverage report
java emma report -r txt -in coverage.ec -in coverage.em
It throws me following error.
C:\>java emma report -r txt -in coverage.ec -in coverage.em
EMMA: processing input files ...
EMMA: 2 file(s) read and merged in 281 ms
com.vladium.emma.EMMARuntimeException: [CLASS_STAMP_MISMATCH] runtime version of
class [com.mcafee.hips.firewall.DataSources.ApplicationDataSource] in the cover
age data is not consistent with the version of this class in the metadata, possi
bly because stale metadata is being used for report generation.
at com.vladium.emma.report.ReportDataModel.getView(ReportDataModel.java:
95)
at com.vladium.emma.report.AbstractReportGenerator.initialize(AbstractRe
portGenerator.java:210)
at com.vladium.emma.report.txt.ReportGenerator.process(ReportGenerator.j
ava:64)
at com.vladium.emma.report.ReportProcessor._run(ReportProcessor.java:255
)
at com.vladium.emma.Processor.run(Processor.java:88)
at com.vladium.emma.report.reportCommand.run(reportCommand.java:139)
at emma.main(emma.java:50)
I tried with all the above possible ways but still it’s throwing me the same error.
Thanks in advance,
Sasmita
Sas,
ReplyDeleteYou'll need to check your source and binaries for versions of com.mcafee.hips.firewall.DataSources.ApplicationDataSource
Possibly, you have more than one somewhere.
Can you also try on another machine - in case someone else has different source code files on theirs - and may not face the same problem.
Thanks Jose.
ReplyDeleteAs per your suggestion I tried on another system with the same coverage.ec and coverage.em file and there it works fine. It's successfully generating the coverage report with out any error.
I don't understand where the problem is. Why this is not working in my first system?
In both the system source and binaries forcom.mcafee.hips.firewall.DataSources.ApplicationDataSource is same.
Thanks again for your suggestion.
Sasmita.
Sasmita,
ReplyDeleteI reckon it is a multiple version issue on your machine. Search only for "ApplicationDataSource" in all JARs - you might have the class under a different package but still appearing in the EMMA classpath and the runtime coverage file.
- Jose
Hi bbossola,
ReplyDelete>> Currently i made a quick patch to Emma runtime to just give me a warning in such situations
Can you please help, on how to instruct Emma to give only a warning here instead of error?
Thanks in advance.
Madhes