Я перенес приложение, которое раньше использовало log4j для logback / slf4j и у меня были проблемы в течение 2 недель ... Я сделал небольшой проект для тестирования logback / slf4j, и он работал отлично, но по какой-то причине при его применении в настоящее приложение просто не хочет работать.

Я использую JBoss 6.2 и внедряю EAR в каталог standalone / deployments и запускаю сервер (что все хорошо и хорошо, за исключением того факта, что я получаю это исключениеjava.lang.ClassCastException: org.slf4j.impl.Slf4jLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext) но все равно вернемся к основной проблеме.

когда я запускаю приложение, я печатаю это в указанный мной файл журнала

 10:51:06.752 [main] DEBUG org.jboss.logging - Logging Provider: org.jboss.logging.Slf4jLoggerProvider
10:51:06.780 [main] DEBUG o.j.n.r.client.InitialContextFactory - Looking for jboss-naming-client.properties using classloader sun.misc.Launcher$AppClassLoader@194d4313
10:51:06.782 [main] DEBUG o.j.n.r.client.InitialContextFactory - jboss.naming.client.endpoint.create.options. has the following options {}
10:51:06.783 [main] DEBUG o.j.n.r.client.InitialContextFactory - jboss.naming.client.remote.connectionprovider.create.options. has the following options {}
10:51:06.789 [main] INFO  org.xnio - XNIO Version 3.0.7.GA-redhat-1
10:51:06.798 [main] INFO  org.xnio.nio - XNIO NIO Implementation Version 3.0.7.GA-redhat-1
10:51:06.815 [main] INFO  org.jboss.remoting - JBoss Remoting version 3.2.18.GA-redhat-1
10:51:06.856 [Remoting "config-based-naming-client-endpoint" read-1] DEBUG org.xnio.nio - Started channel thread 'Remoting "config-based-naming-client-endpoint" read-1', selector sun.nio.ch.WindowsSelectorImpl@2668d102
10:51:06.856 [Remoting "config-based-naming-client-endpoint" write-1] DEBUG org.xnio.nio - Started channel thread 'Remoting "config-based-naming-client-endpoint" write-1', selector sun.nio.ch.WindowsSelectorImpl@2b71ee01
10:51:06.915 [main] DEBUG o.j.n.r.client.InitialContextFactory - jboss.naming.client.connect.options. has the following options {}
10:51:07.393 [main] DEBUG org.hornetq.core.client - Trying reconnection attempt 0/1
10:51:07.401 [main] DEBUG org.hornetq.core.client - Trying to connect with connector = org.hornetq.core.remoting.impl.netty.NettyConnectorFactory@b2e86ae, parameters = {port=5445, host=localhost} connector = NettyConnector [host=localhost, port=5445, httpEnabled=false, useServlet=false, servletPath=/messaging/HornetQServlet, sslEnabled=false, useNio=false]
10:51:07.425 [main] DEBUG org.hornetq.core.client - Started Netty Connector version 3.6.6.Final-redhat-1-fd3c6b7
10:51:07.425 [main] DEBUG org.hornetq.core.client - Trying to connect at the main server using connector :TransportConfiguration(name=netty, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=5445&host=localhost
10:51:07.426 [main] DEBUG org.hornetq.core.client - Remote destination: localhost/127.0.0.1:5445
10:51:07.481 [main] DEBUG org.hornetq.core.client - Reconnection successfull
10:51:07.494 [Thread-1 (HornetQ-client-global-threads-272238939)] DEBUG org.hornetq.utils - using dummy address ffffffe9:6c:ffffff84:ffffffb0:2e:-127
10:51:07.496 [main] DEBUG org.hornetq.core.client - ClientSessionFactoryImpl received backup update for live/backup pair = TransportConfiguration(name=netty, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=5445&host=localhost / null but it didn't belong to TransportConfiguration(name=netty, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=5445&host=localhost
10:51:07.779 [Remoting "config-based-naming-client-endpoint" task-3] ERROR o.j.n.r.p.v1.RemoteNamingStoreV1 - Channel end notification received, closing channel Channel ID c0d4d8c1 (outbound) of Remoting connection 6fb0b6e3 to localhost/127.0.0.1:4447

ТЕМ НЕ МЕНИЕ!!! это все, что напечатано в моем файле журнала, остальная часть log.info/log.warn и т. д. все они напечатаны в отдельный файл / log / server.log

вот мой logback.xml

     <?xml version="1.0" encoding="UTF-8"?>
    <configuration scan="true">
        <appender
            name="ConsoleAppender"
            class="ch.qos.logback.core.ConsoleAppender">


        <encoder>
            <pattern>%-4relative [%thread] %-5level %logger{35} - %msg %n</pattern>
        </encoder>
    </appender>

  <!-- Rollover at midnight each day  -->
    <appender
        name="LOG_AUDIT"
        class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!--  <errorHandler class="org.apache.log4j.helpers.OnlyOnceErrorHandler" /> -->

        <file>${my.logPath}/Logs/MYLOG.log</file>
        <append>true</append>
        <datePattern>'.'yyyy-MM-dd</datePattern>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <FileNamePattern>logFile.%d{yyyy-MM-dd}.log</FileNamePattern>
        </rollingPolicy>

        <!-- encoders are assigned the type
         ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
        <!--<encoder>
            <pattern>&lt;%5p ${obphm.version}&gt; [%d{ISO8601}] %t %c - %m%n</pattern>
        </encoder>-->
        <encoder>
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>

    <appender
        name="ERROR_AUDIT"
        class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!--  <errorHandler class="org.apache.log4j.helpers.OnlyOnceErrorHandler" /> -->
        <file>${my.logPath}/Logs/MYERRORS.log</file>
        <append>true</append>
        <datePattern>'.'yyyy-MM-dd</datePattern>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <FileNamePattern>logFile.%d{yyyy-MM-dd}.log</FileNamePattern>
        </rollingPolicy>

        <!-- encoders are assigned the type
         ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
        <encoder>
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
            <!--<pattern>&lt;%5p ${obphm.version}&gt; [%d{ISO8601}] %t %c - %m%n</pattern>-->
        </encoder>
    </appender>

    <root level="DEBUG">
        <appender-ref ref="LOG_AUDIT" />
        <appender-ref ref="ERROR_AUDIT" />
        <appender-ref ref="ConsoleAppender" />
    </root>
</configuration>

и я также попытался создать jboss-deploy-structure.xml для исключений;

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
    <deployment>
        <exclusions>
            <module name="org.apache.commons.logging" />
            <module name="org.slf4j" />
            <module name="org.slf4j.ext" />
            <module name="org.slf4j.jcl-over-slf4j" />

            <module name="org.slf4j.impl" />
            <module name="org.apache.log4j" />
        </exclusions>
        <dependencies>

            <module name="ch.qos.logback" />
            <module name="org.slf4j.v175" />
        </dependencies>
    </deployment>

</jboss-deployment-structure>

но похоже, что он ничего не делает, он все еще пытается получить доступ к org.slf4j.impl по какой-то причине ... У меня есть папка META-INF для jboss-deploy-structure и ухо logback.xml папки ejbmodule ejb, которые упакованы с ухом (это сделало бы это развертыванием ??)

Я не уверен, что мне не хватает, я надеюсь, что кто-то может помочь