code coverage with jersey dependency injection

We have a jersey(jax-rs) rest web application insturmented with the clover. We use jersey SingletonTypeInjectableProvider for dependency injection. The instrumentation seems to be fine, but during the code coverage, although the code is executed, clover doesnot seem to record the coverage for these injected classes, is there a way to get the coverage for these classes?


5 answers

0 votes

Hi Jagan,

Do you see any code coverage for classes which are not injected by SingletonTypeInjectableProvide? If not:

Do you have a clover.jar in the classpath at runtime? Do you see any error messages in the log, like NoClassDefFoundError? See

If you have clover.jar in the class path and it still not works - how do you run your web application and what flush policy are you using? See

If the flush policy seems to be correct - do you have a clover.db in a location accessible from your web application? Are you using a relative or absolute path? Are you bulding and running on the same machine? Are you using -Dclover.initstring property? See



I do see the code coverage for the classes which are not injected. All the classes are part of the same war and clover.jar is in the war lib. So that part is working fine. For the same application we had spring dependency injection, and clover did seem to figure out the coverage properly.

With jersey DI, I see the code being instrumented but no coverage is being recorded.

The clover dbs are generated using the relative location and moved a different location. Using -Dclover.initstring.prefix is used to point to the absolute location of the db. Flush policy is threaded and interval is set to 1000.

Again only for the classes which are dependency injected there is no coverage when I generate the html report. For all other classes instrumentation, coverage and reporting seems to be just fine.


0 votes

Thanks a lot for your detailed explanation. Indeed, it seems to be an issue related with an injection and not an environment problem. I must admit that I didn't test Clover against Jersey DI - may I ask you to prepare a small code sample (if possible) and attach it to a ticket created at


I may have figured out what is going on, while preparing a small test case. Clover seems to do just fine with jersey DI.

The issue is I have 2 separate projects as part of the build. project-jar is built by the project-war. Clover-setup is called in the project-war with a relative location for the clover db. When compile taget in the project-jar is called from project-war , it updates the correct db but with a absolute location of the db instead of the relative location. This may be the issue.

Is there a way to make these depend project use the same relative location while creating the db?


0 votes

I don't know whether you're using Ant or Maven...

In case of Ant, use the 'relative' attribute:

<clover-setup initstring="relative/path/to/clover.db" relative="true">

In case of Maven, try using the:



Hi Marek,
We have a web project which is built into war. We have multiple dependencies which are being injected via pom.xml. Dependencies are jar files. How would I be able to get coverage for those libraries as well.  Currently I am getting coverage of just my war project.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Wednesday in Opsgenie

Getting the Most out of Atlassian and Opsgenie Together

We’re excited to invite you to this action-packed webinar where we will demonstrate how to integrate Opsgenie’s powerful alerting and on-call management tools with your entire Atlassian stack. Mar...

66 views 0 1
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