commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From simon <>
Subject Re: Turning off commons logging
Date Mon, 02 Jun 2008 20:55:50 GMT

On Mon, 2008-06-02 at 12:36 -0700, John B. Moore wrote:
> > but libs that use commons-logging are not? 
> Apparently not.. If I set it to:
> log4j.rootLogger=OFF, A1, R1
> ..and the commons continued to output.. as in: (a brief sample)
> 2008-06-02 12:06:35,801 DEBUG [org.apache.commons.digester.Digester.sax] 
> - startPrefixMapping(xml,
> 2008-06-02 12:06:35,801 DEBUG [org.apache.commons.digester.Digester.sax] 
> - startPrefixMapping(xmlns,
> 2008-06-02 12:06:35,801 DEBUG [org.apache.commons.digester.Digester.sax] 
> - startElement(,,extension)
> 2008-06-02 12:06:35,801 DEBUG [org.apache.commons.digester.Digester] - 
>   Pushing body text '
> .. obviously it thinks there is a DEBUG setting.

Yes, and that is odd. 

This looks to me like the default formatting for log4j. In other words,
it does look like log4j output rather than java.util.logging or other.

But Commons-logging does not set any logging levels at all, and log4j defaults to INFO. So
this suggests that *somewhere* in your classpath is another log4j configuration file which
is enabling debug-level. But it is definitely not in any of the commons project jarfiles;
any commons project that tried to release a jar with a logging config file in it would get
voted down.

> Are the commons lib messages getting the
> > ConversionPattern that you specify in your config file? If yes, then the
> > right config file is being seen, and you've just not got the log4j
> > command to set the threshold right.
> So I assume that there is some setting or properties file embedded 
> somewhere in the libs..??

Well, as noted above it won't be in any of the commons jars.

Again, if you could follow my suggestion and change the output pattern a
little, that would be useful. If the problem messages do not change,
then that proves a different config file is in use.

> I use JBuilder and therefore the classpath is tightly controlled and is 
> not associated with any classpath elsewhere in my system (Mac OSX 
> 10.5.2)  I've used some of the commons before and never had this issue 
> come up, hence the mystery..

Hmm. Mac OSX. Maybe you should check the JVM files themselves, just
because I've never heard of anyone having this problem before and that
is a less-common platform. Didn't java1.5 just get released for Mac a
few weeks ago? Are you using that brand new release?

> I'm using
> commons-beanutils-bean-collections.jar
> commons-beanutils-core.jar
> commons-beanutils.jar
> commons-codec-1.3.jar
> commons-collections-3.2.1.jar
> commons-httpclient-3.2.1.jar
> commons-lang-2.4.jar
> commons-logging-1.1.1.jar
> I've used commons-collections on occasion with out seeing this effect, 
> but this is the FIRST time I've use so many (due to another library that 
> has all of these as dependencies and yes I check that source and 
> directories for any logging properties files.)
> > 
> > Interestingly, the default logging level for almost all logging libs is
> > "INFO", and commons libs don't log much at INFO level or above. Yet you
> > say that you are getting "massive" amounts of logging. So it would
> > appear that somehow you have a config file in your environment that is
> > forcing logging to a level lower than the default.
> To my knowledge there is only one as listed previously..
> > 
> > You could try putting a file named "" in your
> > app's classpath 
> I did this and it had no effect.. I assume it was because it is not 
> seeing my config file and is seeing something else..?

It's not too surprising it had no effect. I thought that commons-logging
was probably auto-detecting log4j, and so forcing it to use log4j makes
no difference.

There isn't a way for commons-logging to force log4j to choose a
specific config file. How log4j chooses to initialise itself is log4j's

Maybe there is a system property that will force log4j to output
diagnostics about which config file it is using? That info would of
course be in the log4j docs, not commons-logging.

There is an option to force commons-logging to output some diagnostics
which *might* be useful in your case. See the link titled
"Troubleshooting guide" on the commons-logging website.

I'm 95% sure that the issue is that you have another log4j config file
somewhere in your classpath. And that it is NOT inside a commons

As a last resort, you could edit that file to
specify NoOpLog rather than Log4JLog. That should block all messages
logged via commons-logging, although all messages logged directly to
log4j will not be affected. That isn't the best solution of course.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message