Not really a Maven issue but if you do your logging like this:
package com.myco.testapp;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class MyClass{
private Logger
_logger=LoggerFactory.getLogger(this.getClass());
logger.debug(“blah {} in the loop that contains {}”, i, max);
}
You can sort out the enabling of logs and destination of your logging by
severity and class(I think by package as well) in the log configuration
at run-time.
Ron
On 12/02/2014 4:20 PM, Mirko Friedenhagen wrote:
Hello Benoit,
Kevin is right, using slf4j[0] one would use sth. like:
logger.debug(“blah {} in the loop that contains {}”, i, max);
No need for iffing :-).
[0] http://www.slf4j.org/manual.html
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Wed, Feb 12, 2014 at 10:10 PM, Kevin Krumwiede <[email protected]> wrote:
It does matter which implementation. The main reason it was recommended to
check the logging level was because string concatenation can be expensive,
and you want to avoid doing it for a message that won't be logged. But if
you're using a logging API like slf4j that uses parameter replacement
tokens in the message string, if the message isn't logged, the replacement
won't be performed and the call will be cheap.
On Feb 12, 2014 1:57 PM, "Benoît Berthonneau" <[email protected]>
wrote:
Hi Paul,
Don't think that I could play with exclusions. Here is an example :
*A Unit Test :*
*The tested class with ALL traces activated:*
*And the same tested class with INFO traces activated:*
-----Message d'origine-----
De : [email protected] [mailto:[email protected]] De
la part de Paul Benedict
Envoyé : mercredi 12 février 2014 21:36
À : Maven Users List
Objet : Re: Code coverage with debug logs: 100% branch coverage not
possible?...
IIRC, there should be an option in Emma/Cobertura that allows you to
exclude coverage on certain classes. So if you can exclude your log4j
classes (you don't really want to test your logging, do you?), then you
should be able to raise your percentage.
On Wed, Feb 12, 2014 at 2:30 PM, Benoît Berthonneau
<[email protected]>wrote:
Hi all,
I need your opinion/way to tackle the following problem:
In many projects we use a Logger (doesn't matter which
implementation). It is often recommend to test if the debug level is
activated before logging a debug trace like the following:
if (logger.isDebugEnabled()) {
logger.debug("blah " + i + " in the loop that contains " + max);
}
Now when you run unit tests on this kind of code you need to make a
choice:
run tests with INFO level or run tests with ALL traces activated. I
choose the second option in order to:
* Check that debug traces doesn't throw unwanted exception (like
NPE)
* Have a better code coverage in term of covered lines
But in term of branches coverage we could never have a 100% :(
To me the only way to cover this is to run the tests suite 2 times:
one with INFO traces configured, and another one with ALL traces
activated.
Did you face this issue and how did you solve it ?
Thanks,
Benoît.
--
Cheers,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
