У нас также была эта проблема, и поскольку мы должны были настроить ведение журнала с использованием Log4J, это была проблема. Однако использование prefer-application-packages
, похоже, пока что работает, т.е. помещает файл weblogic-application.xml
в папку META-INF
EAR со следующим:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-application.xsd http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd" >
<prefer-application-packages>
<package-name>org.slf4j</package-name>
</prefer-application-packages>
</weblogic-application>
(хорошо, указанный xmlns старый, но он работает, вы можете обновить его, если хотите, я просто взял наш и удалил несвязанные части).
У нас все еще есть вышеупомянутое предупреждение, но оно использует Log4J по мере необходимости. Фактически, если вы посмотрите на URL-адрес, указанный в следующей строке в журналах (здесь опущено в вопросе), он скажет:
Предупреждение, выдаваемое SLF4J, является только предупреждением. SLF4J будет по-прежнему связываться с первым каркасом, который он найдет в пути к классам .
Так что, я думаю, он все еще использует обычный механизм загрузки классов для загрузки org.slf4j.impl.StaticLoggerBinder
, который мы на самом деле сконфигурировали так, чтобы предпочесть тот, что указан в нашем EAR (то есть сделать его первым в пути к классам).
Тем не менее, предупреждение остается, но оно работает. Исправить предупреждение было бы хорошо, но, вероятно, невозможно без изменения предоставленных библиотек WebLogic.