• Community
  • Products
  • Clover
  • Questions
  • Clover is not capturing code coverage percentage for one of the Java Virtual machine application where as it is capturing for anothe application which is using same JVM and running parallel.

Clover is not capturing code coverage percentage for one of the Java Virtual machine application where as it is capturing for anothe application which is using same JVM and running parallel.

 

2 answers

1 vote

1. Please check whether an application log contains messages like:

"CLOVER: Unable to load the coverage database at <path>"
"CLOVER: No coverage data will be gathered."

Thanks to this you will know whether an application located database file correctly.


2. I see that you're using <clover-instr> with default settings for flush policy and flush interval (as they're not defined in your script). Do you terminate both JVMs after tests?

I'm asking because, by default, coverage recording files are being written at JVM shutdown. Which means that if your JVM is running indefinitely, you'll have no coverage recording files. I suggest using <clover-instr flushpolicy="interval"/>.


3. Do you use the same version of clover.jar in both JVMs?


WRT passing any arguments to JVMs: according to your description there's no need to pass any arguments to JVMs.

Thanks Merek..Appreciate your support...It worked for us!! We are able to get code coverage from both the JVMs.

Please can you explain what does <clover-instr flushpolicy="interval"/>. do ?

 

and also we are getting below exception in one of the JVM:

15:31:18,889 INFO [javax.baja.web.BWebServer] Scheduling restart in 5 seconds.
ERROR: java.security.AccessControlException flushing coverage for recorder C:\Clover\honeywellSpyderTool_clover.dbi1as7_i57yz3v8: access denied ("java.io.FilePermission" "C:\Clover" "read")
ERROR: java.security.AccessControlException flushing coverage for recorder C:\Clover\honeywellSpyderTool_clover.dbi1as7_i57yz3v8: access denied ("java.io.FilePermission" "C:\Clover" "read")
ERROR: java.security.AccessControlException flushing coverage for recorder C:\Clover\honeywellSpyderTool_clover.dbi1as7_i57yz3v8: access denied ("java.io.FilePermission" "C:\Clover" "read")
ERROR: java.security.AccessControlException flushing coverage for recorder C:\Clover\honeywellLonSpyder_clover.dbgdlx9_i57yz4as: access denied ("java.io.FilePermission" "C:\Clover" "read")
ERROR: java.security.AccessControlException flushing coverage for recorder C:\Clover\honeywellSpyderTool_clover.dbi1as7_i57yz3v8: access denied ("java.io.FilePermission" "C:\Clover" "read")
ERROR: java.security.AccessControlException flushing coverage for recorder C:\Clover\honeywellSpyderTool_clover.dbi1as7_i57yz3v8: access denied ("java.io.FilePermission" "C:\Clover" "read")
2015-01-22 15:31:24.089:WARN:oejuc.AbstractLifeCycle:webServerConfig: FAILED ServerConnector@4186f4{SSL-HTTP/1.1}{0.0.0.0:443}: java.net.BindException: Address already in use: bind

 

Any signification of this error?

> Please can you explain what does <clover-instr flushpolicy="interval"/>. do ? Please see https://confluence.atlassian.com/display/CLOVER/Using+a+Flush+Policy > ERROR: java.security.AccessControlException flushing coverage for recorder C:\Clover\honeywellSpyderTool_clover.dbi1as7_i57yz3v8: access denied ("java.io.FilePermission" "C:\Clover" "read") Please see https://confluence.atlassian.com/display/CLOVER/Working+with+Restricted+Security+Environments

0 votes

I recommend to check:

  • what initstring has been used in both applications during compilation
    • is default value used or a custom one?
    • is it an absolute or a relative path?
    • are values the same in both applications?
  • whether any of -Dclover.initstring or -Dclover.initstring.basedir parameters are being passed to JVM
    • if yes, then which one?
  • whether clover databases are in locations expected by applications running in JVM
    • it's a combination of current working directory + initstring (if it's a relative path) or
    • it's a combination of -Dclover.initstring.basedir + initstring or
    • it's just a -Dclover.initstring

The most probably one of your applications is unable to read the clover.db file, because it's trying to open it from a wrong location. I suggest checking application logs - there should be a message about it.

 

Thanks Merek

 

Let me rephrase the question. I have 2 JVMs on the same system. I am building a single application and loading it in both the JVMs. I am also creating a single clover database for both the JVMs.

 

When i run the tests manually some portion of the application is executed in the first JVM and some portion is executed in the second JVM.

 

After testing when i generate the coverage report i only get coverage detected for the first JVM. No coverage is detected for code that is executed in the second JVM.

 

Note:

1. Both JVMs run at the same time on the same machine.

 

2. This is the Clover task that we used to instrument the source code.

<clover-instr destdir="@{sourceCodeLoc}/instr" initstring="C:/Clover/@{moduleName}_clover.db" source="1.8">

    <fileset dir="@{sourceCodeLoc}/src"><include name="**/*.java"/></fileset>

</clover-instr>

 

3. We are not passing any arguments while starting both the JVMsEnvironment.png

Suggest an answer

Log in or Sign up to answer
Community showcase
Published 9 hours ago in Jira Ops

Jira Ops Early Access Program Update #2: Let’s talk severity levels

Welcome to your weekly Jira Ops Early access program update, where we’re sharing news and updates on Jira Ops' progress as we work toward our 1.0 release. If you ever want to drop us feedback or idea...

20 views 0 0
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you