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?
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 https://confluence.atlassian.com/x/lwjoEg
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 https://confluence.atlassian.com/x/xxSmEQ
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 https://confluence.atlassian.com/display/CLOVER/Using+Clover+in+various+environment+configurations
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.
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 https://support.atlassian.com?
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?
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:
Back in April of last year one of the major product announcements from Opsgenie was the launch of the Incident investigation view which created a deep connection between Bitbucket and Opsgenie, empow...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events