No coverage being generated from WebLogic hosted instrumented EAR

[banoss]

Hi All,

This seems to be a fairly well documented requirement, but following the instructions available does not generate any test coverage output at all. Only some warning messages in the logs. And I cant find additional information to troubleshoot further.

I've tested with clover-3.0.2 and clover-2.6.3 and followed these instructions https://confluence.atlassian.com/display/CLOVER030/Working+with+Distributed+Applications

Deploying the instrumented ear, copying the cloverMerge.db and clover jar into th classpath of the server. Server command line contains (and these are reiterated in the server logs as is the correct clover jar being loaded)

-Dclover.initstring=/data/app/logs/cloverMerge.db

I've also tried adding

-Dclover.server=true
-Dclover.distributed.coverage=ON

even

-Dclover.offrails.coverage=true

I do see the following message in the console log of the managed node server

WARN: CLOVER: Clover database: '/data/app/logs/cloverMerge.db' can only be used for reporting because it is the result of a merge.
WARN: CLOVER: Coverage data for some classes will not be gathered.

But nothing else. No coverage files are created along side the clover db. There's no additional log entries.

The process can definately write to that location - hence the logs directory :)

I've set some java policy as described in one blog entry

//testing clover
//remove when done
permission java.util.PropertyPermission "*", "read";
permission java.io.FilePermission "<>", "read, write";
permission java.lang.RuntimePermission "shutdownHooks";

The build the ear comes from is setting flushpolicy=threaded flushinterval=5000 and produces clover reports absolutely fine. The ear definately contains clover instrumented sources. I've even tried adding these properties to the server JVM startup command with the others. I've also tried shutting down the server after the tests incase the flush is still only happening on the shutdown hook - using the WebLogic console to do this.

The tests that run against the application are driven from some external scripts that run end-to-end tests that are definately hitting the functions as I can see the tests are passing and the output.

All the instructions seem so simple, so I must have missed something obvious I hope... otherwise how do I see more output from Clover in order to continue troubleshooting?

Many thanks,

Banos

[Liz Maritz]

Hi Marek / @banos banos- I know this is an old post so hopefully you will see this comment. We are trying to run an instance of Clover with the ability to create dynamic reports from a running Weblogic instance. Is this related to the topic above? Would we employ any of the same logic? Please let me know if I can clarify or provide more context / detail. Thanks!

[Marek Parfianowicz]

Hi Elizabeth, "We are trying to run an instance of Clover with the ability to create dynamic reports from a running Weblogic instance". Do I understand correctly that you'd like to generate reports without shutting down the Weblogic instance? And/or to refresh them as test progresses? Is yes, then you shall use "interval" or "threaded" flush policy for this purpose. "Please let me know if I can clarify or provide more context / detail." Yes, feel free to provide more details - either on this forum or in a support ticket (support.atlassian.com). Cheers Marek

[Steve Bromley (javapgmr)]

@Marek Parfianowicz I'll answer for Elizabeth Maritz. We are trying to instrument (with Clover) an existing running application that runs in WebLogic. Are there any good 'knowledge' articles that you can point us at on how we would accomplish this? I've found some bits and pieces but haven't found a definitive article as of yet. Any help and/or guidance you can provide would be greatly appreciated.

[Marek Parfianowicz]

Hi Steve, "We are trying to instrument (with Clover) an existing running application that runs in WebLogic." Please note that Clover uses source code instrumentation. Which means that you have to recompile your code with Clover and next deploy such instrumented application into your WebLogic server. It's not possible by Clover to dynamically attach to a JVM running some non-instrumented application and to measure code coverage "on the fly" (i.e. without rebuilding a code and without re-deploying). If this is really what you need then you'd have to look for java-agent / JVMTI based code coverage tools. "Are there any good 'knowledge' articles that you can point us at on how we would accomplish this?" There's no single article, I'm afraid. I suggest to start from this point: * https://confluence.atlassian.com/display/CLOVER/Using+Clover+for+web+applications Shortly speaking what you have to do is: * compile your web app with Clover (to have classes instrumented by Clover) ** use 'threaded' or 'interval' flush policy to have coverage data being written to disk continuously * deploy web app to a WebLogic server ** ensure that clover.db file(s) is copied as well as Clover needs it at runtime ** ensure that clover.jar is available on class path (bundle it into WEB-INF/lib or put into application server's /lib * run your tests; as soon as application starts, Clover will start writing coverage files to disk * after tests are finished (or during test execution if you need results in the meantime) ** copy coverage recording files (clover.db*) back to your build machine (under assumption that your WebLogic runs on a different machine) ** run report generation Optionally, you could also configure the "distributed per-test coverage" feature. See a diagram how it could look like on this page: * https://confluence.atlassian.com/display/CLOVER/Using+Clover+for+web+applications#UsingCloverforwebapplications-WebApp

[Steve Bromley (javapgmr)]

@Marek Parfianowicz Thank you. There is a lot to absorb on this. I really appreciate the information and starting point. I'll see what I can come up with.

[Marek Parfianowicz]

You're welcome! Feel free to ask.

[Marek Parfianowicz]

Please note that in the question https://answers.atlassian.com/questions/22316/clover-on-j2ee-manual-testing I had mentioned about merging of database files, but this has to be done after running tests. In general we have two approaches for multi-module builds:

1. create separate clover.db for every module, run every module separetely (*), next merge coverage results into one cloverMerge.db and generate a coverage report
2. create single clover.db for whole application, run whole application, (no need to merge), next generate a coverage report

(*) You can run modules on different machines. Or on the same machine, but then coverage for every module is written to different directory - in such case relative paths must be used during compilation and execution (clover.initstring.basedir or clover.initstring.prefix)

Regards
Marek

[Marek Parfianowicz]

Hello Banos,

As you can see in the warning message:

WARN: CLOVER: Clover database: '/data/app/logs/cloverMerge.db' can only be used for reporting because it is the result of a merge.

You cannot use a cloverMerge.db for coverage recording. Merged database can be used only for reporting. I guess that you have a multi-module build (e.g. built by Maven) and that's why you wanted to use a merged database. If this is the case, please use the "single database" feature.

Define in your top-level pom.xml following properties for maven-clover2-plugin:

<cloverDatabase>/path/to/your/singleClover.db</cloverDatabase>

<singleCloverDatabase>true</singleCloverDatabase>

and do not define any <cloverDatabase> path in pom.xml(s) in child modules.

Thanks to this, after build you will have single registry database created for whole application.

Next, follow steps described by you, i.e. deploy the instrumented ear, copy the singleClover.db and clover jar into classpath of the server and add a server command line option like:

-Dclover.initstring=/data/app/logs/singleClover.db

Regards
Marek

[banoss]

I've now found this similar question which I used to follow the given instructions to no avail https://answers.atlassian.com/questions/22316/clover-on-j2ee-manual-testing