Могу ли я отключить c3p0 от входа в System.err? - PullRequest
8 голосов
/ 28 июля 2011

Согласно документации c3p0 , вы можете вручную указать, куда должны вести журналы, будь то ведение журнала JDK 1.4, Log4j или System.out.Я использую SLF4J, поэтому я включил org.slf4j.jul-to-slf4j и вызываю SLF4JBridgeHandler.install() в своем приложении, чтобы заставить все журналы утилит Java проходить через SLF4J.Кроме того, я включил в свой файл c3p0.properties следующее свойство:

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

Это, согласно документации, заставит c3p0 регистрироваться в журнале JDK 1.4, что, в свою очередь, приведет к выходу из системыSLF4J.Это работает несколько, но я все еще вижу, что некоторые журналы нажимают System.err:

Пример 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]

Строки 1 и 6 выше записаны в SLF4J, другие записаныSystem.err.

Пример 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 ]

Первые две строки выше записаны в System.err, что не имеет никакого смысла, так как оно также регистрируется вSLF4J как задумано.

Есть ли способ отключить ведение журнала на System.err с c3p0?

Ответы [ 5 ]

9 голосов
/ 28 июля 2011

Я бы предложил попробовать связывание log4j и настроить c3p0 для его использования.

java.util.logging - одна из самых запутанных вещей, с которыми я когда-либо работал.

3 голосов
/ 31 марта 2014

Поскольку принятый ответ был написан (почти три года назад), в версию 0.2.5 артефакта mchange-commons-java была добавлена ​​прямая поддержка входа slf4j в любой бэкэнд, то есть то, что использует документация c3p0 .

Например: 'com.mchange.v2.log.MLog = com.mchange.v2.log.slf4j.Slf4jMLog'

Однако ... Последний стабильный выпуск в Maven Central (0.9.2.1) c3p0 не использует эту версию. Для использования этой конфигурации вам нужно будет обновить ее как минимум до 0.9.5-pre2. Последняя неизданная версия: 0.9.5-pre7

Это позволит избежать необходимости:

  1. Измените общий бэкэнд регистрации на log4j, ИЛИ
  2. Используйте 'двойной прыжок' для маршрутизации входа в мост, предоставленный в другом ответе.

Это то, что мы делаем для маршрутизации в slf4j и logback. Однако в одном приложении нам все еще нужно использовать мост log4j, пока не будет выпущена новая версия hibernate hibernate-c3p0, которая обновит версию c3p0.

Я подозреваю, что это одна из проблем, на которую ссылается ответ FredCooke ... но это может сбить с толку две проблемы. Hibernate переносит зависимость jboss-logging в путь к классам, но он будет разумно использовать logback уже, если он присутствует. Однако для c3p0 необходимо дополнительно настроить com.mchange.v2.log.MLog = com.mchange.v2.log.log4j.Log4jMLog для отправки его записей журнала в log4j, который затем будет перехвачен мостом 'log4j => slf4j'.

3 голосов
/ 18 февраля 2013

Добавление следующей зависимости решает некоторые проблемы, но не все.

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

В дополнение к этому, вам нужно обойти раздражающую логику в этом файле:

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

Предоставляя этот пустой класс:

org.apache.log4j.Hierarchy

Некоторые дебаты по этому вопросу можно найти здесь:

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

Я планирую создать для этого отдельную зависимость класса, которая зависит от log4j-over-slf4j, однако она работает как есть в одном проекте. Теперь я могу переключиться с slf4j-nop на slf4j-simple для входа в систему и получить ожидаемые результаты как из собственного кода, так и из Hibernate / C3P0.

2 голосов
/ 02 апреля 2012

Если вы используете log4j-over-slf4j , MLog c3p0 зарегистрирует этот «фальшивый» log4j, который, в свою очередь, будет slf4j, тогда вы можете использовать любой провайдер, который предпочитаете для вывода slf4j.

РЕДАКТИРОВАТЬ: Это работало, когда я использовал его и представил этот ответ, но они специально сломали это пару месяцев спустя.См. Дополнительные изменения, необходимые в FredCooke ответ .

0 голосов
/ 28 июля 2011

Вы можете настроить System.err для указания на другой PrintStream с помощью System.setErr ().Он не изменяет C3PO, но выходные данные журнала будут отображаться там, где вы хотите.

...