How can I get rid of Log4j logging in unit tests?

[frank]

Hello,

My question is about the Log4j logging system.

I wrote some code using the Spring JDBC framework and I wrote some
JUnit tests for my code. When I run the tests, Spring outputs thousands
of debug statements to Log4j, which end up in my test report, making it
very hard to read.

I appreciate the fact that Log4j is a complex system with many ways to
configure and control it. That's all well and good, but frankly, I
don't have time to spend a week learning how it works, and I'm not in
the mood to create a configuration file and figure out where it needs
to be when I run my tests. All I want to do is put a line or two of
code in my unit test that will shut off the offending log messages.

Can someone enlighten me?

I tried this, but it doesn't work:

org.apache.log4j.BasicConfigurator.configure();
LogManager.getLoggerRepository().setThreshold(Level.INFO);

 

[Antti S. Brax]

I appreciate the fact that Log4j is a complex system with many ways to
configure and control it. That's all well and good, but frankly, I
don't have time to spend a week learning how it works, and I'm not in
the mood to create a configuration file and figure out where it needs
to be when I run my tests. All I want to do is put a line or two of
code in my unit test that will shut off the offending log messages.

Can someone enlighten me?

<snip>

Frankly, I don't have time to be polite.

RTFM!

 

[Ingo R. Homann]

Hi,

Hello,

My question is about the Log4j logging system.

I wrote some code using the Spring JDBC framework and I wrote some
JUnit tests for my code. When I run the tests, Spring outputs thousands
of debug statements to Log4j, which end up in my test report, making it
very hard to read.

I appreciate the fact that Log4j is a complex system with many ways to
configure and control it. That's all well and good, but frankly, I
don't have time to spend a week learning how it works, and I'm not in
the mood to create a configuration file and figure out where it needs
to be when I run my tests. All I want to do is put a line or two of
code in my unit test that will shut off the offending log messages.

Can someone enlighten me?

I tried this, but it doesn't work:

org.apache.log4j.BasicConfigurator.configure();
LogManager.getLoggerRepository().setThreshold(Level.INFO);

Perhaps, the following may work:

Logger.getRootLogger().removeAllAppenders();

....or something like that.

Hth,
Ingo

 

[flarosa]

But you had time to insult me. That was nice.

I spend half my day reading documentation -- documentation for stuff
that's important to the applications I'm trying to produce. Database
servers, JBoss, EJBs, XML parsers, Ant, Spring, etc. After the amount
of work I do every day to get my actual code to work, I don't need to
spend another six hours learning about some logging system that means
nothing to me except that it messes up my unit tests.

I guess logging is a big deal to some people. Big enough that they had
to produce a couple hundred logging classes, which I have in fact been
reading through for the last two hours trying to solve my problem. One
would believe that setting the threshold on something called either the
"Root logger" or the "Logger repository" would do the trick. But it
does not, and if there is more complexity to this "log4j" system than
that, then it is complexity I don't need to know about and don't care
to learn.

All I want to do is read my freaking unit test results without a
thousand DEBUG messages in them coming from some framework I didn't
write.

Unless I'm the only person who writes unit tests, I can't believe I'm
the first person to have this kind of a problem.

 

[flarosa]

Sounds reasonable, but it doesn't work.

Could the problem be that the Spring framework itself is somehow
reconfiguring the logger after me?

Nothing I do in my code before starting my test seems to have any
effect.

I know there is no other log4j configuration file other than the one in
my application server, which is nowhere near the unit tests.

 

[Ingo R. Homann]

Hi,

Sounds reasonable, but it doesn't work.

Was just an idea.

Could the problem be that the Spring framework itself is somehow
reconfiguring the logger after me?

Yes, I think so...

Can you call removeAppenders() later?

I know there is no other log4j configuration file other than the one in
my application server, which is nowhere near the unit tests.

Have you searched in all jars as well?

Ciao,
Ingo

 

[Raymond DeCampo]

But you had time to insult me. That was nice.

I spend half my day reading documentation -- documentation for stuff
that's important to the applications I'm trying to produce. Database
servers, JBoss, EJBs, XML parsers, Ant, Spring, etc. After the amount
of work I do every day to get my actual code to work, I don't need to
spend another six hours learning about some logging system that means
nothing to me except that it messes up my unit tests.

I guess logging is a big deal to some people. Big enough that they had
to produce a couple hundred logging classes, which I have in fact been
reading through for the last two hours trying to solve my problem. One
would believe that setting the threshold on something called either the
"Root logger" or the "Logger repository" would do the trick. But it
does not, and if there is more complexity to this "log4j" system than
that, then it is complexity I don't need to know about and don't care
to learn.

All I want to do is read my freaking unit test results without a
thousand DEBUG messages in them coming from some framework I didn't
write.

Unless I'm the only person who writes unit tests, I can't believe I'm
the first person to have this kind of a problem.

It would be much easier to take an example log4j configuration file and
hack it down that to sort through all the source code. The
configuration file (either properties format or XML format) needs only
be in your classpath. Start with the one from your app server.

Or just | grep -v DEBUG.

Ray

 

[samspot]

Did you ever solve this problem? I'm having the exact opposite problem... Logging is working in my web app but no my unit tests.