code coverage with jersey dependency injection

[Jagan Gowder]

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?

Thanks

[Marek Parfianowicz]

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:

<cloverDatabase>relative/path/to/clover.db</cloverDatabase>

<singleCloverDatabase>true</singleCloverDatabase>

[422vishal]

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.

[Jagan Gowder]

Marek,

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?

Thanks

[Marek Parfianowicz]

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?

[Jagan Gowder]

Marek,

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

[Marek Parfianowicz]

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 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

Cheers
Marek