c3p0 file not found error

Question

Я использую j3 c3p0-0.9.2.1, и у меня есть этот jar в моем пути к папке и папке lib. Всякий раз, когда я подключить первый раз, когда я получаю эту ошибку:

com.mchange.v2.cfg.DelayedLogItem [ level -> FINE, text -> "The configuration file for resource identifier '/mchange-commons.properties' could not be found. Skipping.", exception -> java.io.FileNotFoundException: Resource not found at path '/mchange-commons.properties'.] 
com.mchange.v2.cfg.DelayedLogItem [ level -> FINE, text -> "The configuration file for resource identifier 'hocon:/reference,/application,/' could not be found. Skipping.", exception -> java.io.FileNotFoundException: HOCON lib (typesafe-config) is not available. Also, no resource available at '/reference,/application,/' for HOCON identifier 'hocon:/reference,/application,/'.] 

Мое приложение работает нормально though.i я не в состоянии оценить то, что эта ошибка и я должен беспокоиться об этой ошибке Если да, то каким образом? чтобы удалить эту ошибку. Что я делаю неправильно.

Answer 1

Это сообщения уровня DEBUG, в основном документирующие c3p0, проверяющие всю информацию о конфигурации различных мест, и обычно не обнаруживают ничего в большинстве этих мест. FileNotFoundExceptions - это то, как c3p0 видит, что там ничего нет.

c3p0 и библиотеки под com.mchange в общем предназначены для входа на уровень INFO для нормального использования. Если вы заходите в DEBUG или FINE, вы можете увидеть больше вещей, чем хотите, включая такие вещи, как эти совершенно безобидные ожидаемые FileNotFoundExceptions во время поиска файлов конфигурации.

Answer 2

Я просмотрел класс DelayedLogItem в пакете cp30, а также отладил код.

Кажется, что этот класс не использует logback или любой регистратор. На самом деле он делает что-то похожее на большинство регистраторов, определяет его собственные уровни журналов и т. Д. Сообщение журнала на самом деле является результатом метода toString().

Во время отладки я обнаружил, что класс BasicMultiPropertiesConfig пытается найти некоторые файлы конфигурации, а когда нет, он вызывает метод dumpToSysErr, который выводит строки журнала на стандартную ошибку.

Таким образом, похоже, что ни один регистратор не может «ловить» это сообщение журнала и показывать его на основе конфигурации вашего регистратора.

Кстати, если вы настроили, например, logback для ведения журнала TRACE на com.mchange, затем он также регистрируется с использованием logback (включая stacktraces).