Ron, Mirko, Kevin, Thanks for your feedback : you're right with Slf4j implementation. Unfortunately, it is not. It is a home made logger interface implemented by Log4j.
Benoît > Le 12 févr. 2014 à 23:25, Ron Wheeler <[email protected]> a > écrit : > > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
