Can I disable c3p0 from logging to System.err?

Question

According to the c3p0 documentation, you can manually specify where logs should go, whether through JDK 1.4 logging, Log4j, or through System.out. I'm running SLF4J, so I've included org.slf4j.jul-to-slf4j and call SLF4JBridgeHandler.install() in my application to force all Java util logging to go through SLF4J. Additionally, I've included the following property in my c3p0.properties file:

com.mchange.v2.log.MLog = com.mchange.v2.log.jdk14logging.Jdk14MLog

This, according to the documentation, will force c3p0 to log to JDK 1.4 logging, which in turn will log things out to SLF4J. This does work somewhat, but I'm still seeing some logs hit System.err:

Example 1:

17:24:32.648 [main] INFO  com.mchange.v2.log.MLog - MLog clients using java 1.4+ standard logging.
Jul 27, 2011 5:24:32 PM com.mchange.v2.log.MLog <clinit>
INFO: MLog clients using java 1.4+ standard logging.
Jul 27, 2011 5:24:32 PM com.mchange.v2.c3p0.C3P0Registry banner
INFO: Initializing c3p0-0.9.1.2 [built 21-May-2007 15:04:56; debug? true; trace: 10]
17:24:32.754 [main] INFO  com.mchange.v2.c3p0.C3P0Registry - Initializing c3p0-0.9.1.2 [built 21-May-2007 15:04:56; debug? true; trace: 10]

Lines 1 and 6 above are written to SLF4J, the others are written to System.err.

Example 2:

Jul 27, 2011 5:24:33 PM com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource getPoolManager
INFO: Initializing c3p0 pool... com.mchange.v2.c3p0.ComboPooledDataSource [ acquireIncrement -> 3, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, dataSourceName -> z8kflt8huk1hupkhyfms|13b33a0e, debugUnreturnedConnectionStackTraces -> false, description -> null, driverClass -> org.sqlite.JDBC, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, identityToken -> z8kflt8huk1hupkhyfms|13b33a0e, idleConnectionTestPeriod -> 0, initialPoolSize -> 3, jdbcUrl -> jdbc:sqlite:/tmp/floodstream.db, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxIdleTime -> 1800, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 10, maxStatements -> 0, maxStatementsPerConnection -> 0, minPoolSize -> 3, numHelperThreads -> 3, numThreadsAwaitingCheckoutDefaultUser -> 0, preferredTestQuery -> null, properties -> {user=******, password=******}, propertyCycle -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> false, unreturnedConnectionTimeout -> 0, usesTraditionalReflectiveProxies -> false ]
17:24:33.603 [main] INFO  com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource - Initializing c3p0 pool... com.mchange.v2.c3p0.ComboPooledDataSource [ acquireIncrement -> 3, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, dataSourceName -> z8kflt8huk1hupkhyfms|13b33a0e, debugUnreturnedConnectionStackTraces -> false, description -> null, driverClass -> org.sqlite.JDBC, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, identityToken -> z8kflt8huk1hupkhyfms|13b33a0e, idleConnectionTestPeriod -> 0, initialPoolSize -> 3, jdbcUrl -> jdbc:sqlite:/tmp/floodstream.db, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxIdleTime -> 1800, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 10, maxStatements -> 0, maxStatementsPerConnection -> 0, minPoolSize -> 3, numHelperThreads -> 3, numThreadsAwaitingCheckoutDefaultUser -> 0, preferredTestQuery -> null, properties -> {user=******, password=******}, propertyCycle -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> false, unreturnedConnectionTimeout -> 0, usesTraditionalReflectiveProxies -> false ]

The first two lines above are logged to System.err, which doesn't make any sense at all, since it's also logging to SLF4J as intended.

Is there a way for me to disable logging to System.err from c3p0?

Answer 1

I would suggest giving the log4j binding a try, and configuring c3p0 to use that.

java.util.logging is one of the more confusing things I've ever worked with.

Answer 2

Adding the following depedency takes care of some of the problem, however not all of it.

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>log4j-over-slf4j</artifactId>
    <version>1.7.2</version><!-- Or whatever you want/need... -->
</dependency>

In addition to that, you need to bypass the irritating logic in this file:

https://github.com/jboss-logging/jboss-logging/blob/master/src/main/java/org/jboss/logging/LoggerProviders.java#L93

By providing this empty class:

org.apache.log4j.Hierarchy

Some debate on the issue can be found here:

https://issues.jboss.org/browse/JBLOGGING-65

I plan to create a single class dependency that depends on log4j-over-slf4j for this purpose, however it's working as-is in one project. I can now switch from slf4j-nop to slf4j-simple to logback and get the expected results, both from my own code, and from Hibernate/C3P0.