| Цитата |
разве будет исполнаться логгированиэ если в CLASSPATH небудет log4.jar
|
Действительно, я был неправ.
Вопрос оказался весьма интересным и вот что удалось найти:
Как известно, полиморфизм в Java реализован посредством позднего или, как иногда пишут, dynamic-связывания. На нем работает и JCL, получая полный спектр описанных проблем с ClassLoader'ами:
| Цитата |
If commons-logging.jar is in the system classpath in a J2EE environment, the "current" or "thread context" classloader for each individual webapp contains WEB-INF/lib, but commons-logging itself is loaded in the system (parent) classpath. commons-logging looks for log4j using the thread-context classloader and therefore will "see" log4j in WEB-INF/lib, but tries to actually load it in the system classpath, and breaks with a NoClassDefFoundError.
|
Происходит это потому, что на этапе компиляции невозможно однозначно разрешить вызовы переходников от JCL к конкретным логгерам такого вида:
| Код |
LogFactory.getLog("logger.name.not.important.here");
|
В отличие от JCL, SLF4J вызывает статические методы своих переходников, таких как slf4j-log4j, а эти вызовы могут быть разрешены уже на этапе компиляции. Единственное, что остается прояснить, так это как удается использовать разные логгеры при связях на статике. Для этого SLF-api компилируется вместе с классом-затычкой StaticLoggerBinder, который не входит потом в slf4j-api.jar. Вместо этого во время выполнения используется аналогичный по названию, но разный по содержанию StaticLoggerBinder конкретного переходника. И раз вызовы API разрешены на этапе компиляции, то никакие загрузчики классов не участвуют в привязке API к конкретному логгеру. |