Многие столкнулись с проблемой commons-logging и log4j в tomcat. Проблемы проицходят изза class loader'ов (http://articles.qos.ch/classloader.html). Есть такая штука как slf4j. Она типа ресолвит логгеры статически (static linking). Так вот вопрос, что имеется в виду как говорится о static linking ?

Под static linking понимается тот факт, что будет использован тот логгер, который вы положите в CLASSPATH. Если там лежит slf-simple, то вы получите вывод в System.out, если slf-log4j, то будет использован log4j и т. д.

Да но, если будет использоватся log4j, то почему теряется проблема classloaderа ? log4j как я понимаю дальше будет загружатся как обычно. Да и при том если не испльзовать slf, то ведь все джары тоже в CLASSPATH лежат, но потом оказывается что есть проблемы с classloaderми.

потому что самого log4j (для примера) в CLASSPATH может и не быть, а если он будет, то абсолютно неважно какой он был загружен динамически. На самом деле логгирование будут осуществлять классы slf4j-log4j с использованием предложенного log4j конфига.

На самом деле это оказалось не так, см. пост ниже


Это сообщение отредактировал(а) jk1 - 1.4.2010, 23:38

разве будет исполнаться логгированиэ если в CLASSPATH небудет log4.jar ? в самом slf4j нету ведь парсера log4j конфига да и инициализатора, там толка так сказать адаптары к другому фрамеворку по логировании.

Действительно, я был неправ.

Вопрос оказался весьма интересным и вот что удалось найти:

Как известно, полиморфизм в Java реализован посредством позднего или, как иногда пишут, dynamic-связывания. На нем работает и JCL, получая полный спектр описанных проблем с ClassLoader'ами:

Происходит это потому, что на этапе компиляции невозможно однозначно разрешить вызовы переходников от JCL к конкретным логгерам такого вида:
 
В отличие от JCL, SLF4J вызывает статические методы своих переходников, таких как slf4j-log4j, а эти вызовы могут быть разрешены уже на этапе компиляции. Единственное, что остается прояснить, так это как удается использовать разные логгеры при связях на статике. Для этого SLF-api компилируется вместе с классом-затычкой StaticLoggerBinder, который не входит потом в slf4j-api.jar. Вместо этого во время выполнения используется аналогичный по названию, но разный по содержанию StaticLoggerBinder конкретного переходника. И раз вызовы API разрешены на этапе компиляции, то никакие загрузчики классов не участвуют в привязке API к конкретному логгеру.

Это сообщение отредактировал(а) jk1 - 2.4.2010, 07:23