Не может заставить SLF4J работать со стеклянными рыбками 4

Я сконфигурировал Glassfish 3, чтобы использовать SLF4J в прошлом, используя мост SLF4J JUL, и он работал нормально. Проблема, с которой я столкнулся сейчас, заключается в том, что если я использую одну и ту же настройку, SLF4J жалуется на то, что дубликаты SLF4J привязаны к пути к классам, и после поиска в самой стеклянной платке содержится эта ссылка.

Как мне заставить работать SLF4J? Я попытался сделать свою зависимость от SLF4J-API, как это предусмотрено, а затем удалил LogBack Classic, так как glassfish уже содержит некоторый код восстановления. Выполнение этих действий не дает никаких успешных результатов.

Вальтер

Ответ 1

Это может помочь вам

Загрузите Glassfish 4, SLF4J и Logback

Стоп gf4

$GF_INSTALL\bin>asadmin stop-domain

а затем

Скопировать

июлю к SLF4J-1.7.5

SLF4J-апи-1.7.5

Logback-ядро-1.0.13

Logback-классический 1.0.13

$GF_INSTALL/GlassFish/Library/одобрила

Создайте logback.xml в

$GF_INSTALL/GlassFish/домены/domain1/конфигурации

содержащий

<configuration debug="true" scan="true">
    <appender name="FILE" class="ch.qos.logback.core.FileAppender">
        <file>/tmp/gf_server.log</file>
        <append>true</append>
        <encoder>
            <Pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{52} - %msg%n</Pattern>
        </encoder>
    </appender>
    <root>
        <level value="INFO"/>
        <appender-ref ref="FILE"/>
    </root>
</configuration>

Изменить

$GF_INSTALL/GlassFish/домены/domain1/конфигурации/logging.properties

и замените

handlers=java.util.logging.ConsoleHandler
handlerServices=com.sun.enterprise.server.logging.GFFileHandler
java.util.logging.ConsoleHandler.formatter=com.sun.enterprise.server.logging.UniformLogFormatter
com.sun.enterprise.server.logging.GFFileHandler.formatter=com.sun.enterprise.server.logging.ODLLogFormatter
com.sun.enterprise.server.logging.GFFileHandler.file=${com.sun.aas.instanceRoot}/logs/server.log
com.sun.enterprise.server.logging.GFFileHandler.rotationTimelimitInMinutes=0
com.sun.enterprise.server.logging.GFFileHandler.flushFrequency=1
java.util.logging.FileHandler.limit=50000
com.sun.enterprise.server.logging.GFFileHandler.logtoConsole=false
com.sun.enterprise.server.logging.GFFileHandler.rotationLimitInBytes=2000000
com.sun.enterprise.server.logging.GFFileHandler.excludeFields=
com.sun.enterprise.server.logging.GFFileHandler.multiLineMode=true
com.sun.enterprise.server.logging.SyslogHandler.useSystemLogging=false
java.util.logging.FileHandler.count=1
com.sun.enterprise.server.logging.GFFileHandler.retainErrorsStasticsForHours=0
log4j.logger.org.hibernate.validator.util.Version=warn
com.sun.enterprise.server.logging.GFFileHandler.maxHistoryFiles=0
com.sun.enterprise.server.logging.GFFileHandler.rotationOnDateChange=false
java.util.logging.FileHandler.pattern=%h/java%u.log
java.util.logging.FileHandler.formatter=java.util.logging.XMLFormatter

handlers=org.slf4j.bridge.SLF4JBridgeHandler
handlerServices=com.sun.enterprise.server.logging.GFFileHandler
java.util.logging.ConsoleHandler.formatter=com.sun.enterprise.server.logging.UniformLogFormatter
com.sun.enterprise.server.logging.GFFileHandler.formatter=com.sun.enterprise.server.logging.ODLLogFormatter
com.sun.enterprise.server.logging.GFFileHandler.file=/tmp/server.log
com.sun.enterprise.server.logging.GFFileHandler.rotationTimelimitInMinutes=0
com.sun.enterprise.server.logging.GFFileHandler.flushFrequency=1
java.util.logging.FileHandler.limit=50000
com.sun.enterprise.server.logging.GFFileHandler.logtoConsole=false
com.sun.enterprise.server.logging.GFFileHandler.rotationLimitInBytes=2000000
com.sun.enterprise.server.logging.GFFileHandler.excludeFields=
com.sun.enterprise.server.logging.GFFileHandler.multiLineMode=true
com.sun.enterprise.server.logging.SyslogHandler.useSystemLogging=false
java.util.logging.FileHandler.count=1
com.sun.enterprise.server.logging.GFFileHandler.retainErrorsStasticsForHours=0
log4j.logger.org.hibernate.validator.util.Version=warn
com.sun.enterprise.server.logging.GFFileHandler.maxHistoryFiles=0
com.sun.enterprise.server.logging.GFFileHandler.rotationOnDateChange=false
java.util.logging.FileHandler.pattern=%h/java%u.log
com.sun.enterprise.server.logging.GFFileHandler.formatter=com.sun.enterprise.server.logging.UniformLogFormatter
com.sun.enterprise.server.logging.GFFileHandler.alarms=false

Добавьте два новых параметра JVM в

предметной области > configs- > config- > Java-конфигурации

$GF_INSTALL/GlassFish/домены/domain1/конфигурации/domain.xml

<jvm-options>-Djava.util.logging.config.file=${com.sun.aas.instanceRoot}/config/logging.properties</jvm-options>
<jvm-options>-Dlogback.configurationFile=file:///${com.sun.aas.instanceRoot}/config/logback.xml</jvm-options>

затем снова запустите gf4

$GF_INSTALL\bin > начальный домен asadmin

Ответ 2

Если у кого-то есть проблемы с настроенным ch.qos.logback.core.rolling.RollingFileAppender, у меня может быть решение для вас.

Проблема заключается в том, что, следуя инструкциям @vzamanillo, logback сам инициализируется дважды. Это вызвано изоляцией класса GlassFish (один раз с помощью основного ClassLoader, один раз EAR ClassLoader). Это становится видимым, если вы настраиваете logback с помощью debug=true. Если теперь используется RollingFileAppender, два OutputStreams были открыты в том же настроенном файле журнала. Это предотвращает удаление файла журнала во время опроса (отображается в режиме отладки).

Чтобы устранить эту проблему, я переместил библиотеки с /modules/endorsed на /domains/domain1/lib/ext. Теперь GlassFish 4 (конкретный Payara) инициализирует logback только один раз, и все работает так, как ожидалось.

Кстати: для замены записи JUL, указывая <contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator" />, это ДОЛЖНО, иначе вы столкнулись с большими проблемами производительности.

Чтобы отправить также лог файлы потенциальных сторонних библиотек на SLF4j, не забудьте также установить и диспетчерские банки, которые являются i.e.:

JCL-над-slf4j.jar
июлю к slf4j.jar
log4j-над-slf4j.jar