1 2 Previous Next 15 Replies Latest reply: Aug 31, 2012 11:21 AM by James Perkins RSS

Logging with slf4j in 7.1.0.Final

Dan D Newbie

Hi All,

 

In 7.1.0.CR1b I could include my own slf4j-api/slf4j12 and log4j.xml and have my application not use the JBoss logging modules.

 

I did this for the following reasons:

1. JBoss logging seems to be based on java.util.logging, which has no support for Message Diagnostic Context, which I use heavily

2. JBoss logging currently has no support for JMS Appenders like org.apache.log4j.net.JMSAppender

 

Based on what I see in this JIRA, and what I am seeing since I upgraded from CR1b to Final, it seems like JBoss logging has been forced onto us.

https://issues.jboss.org/browse/AS7-1389

"Log API dependencies should be included automatically in deployments"

 

The JIRA mentions being able to exclude the logging dependencies if I want to bring in my own.

 

I created a jboss-deployment-structure file

 

<jboss-deployment-structure>
    <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
    <deployment>
        <exclusions>
            <module name="org.slf4j"/>
            <module name="org.apache.commons.logging"/>
            <module name="org.log4j"/>
        </exclusions>
    </deployment>
</jboss-deployment-structure>

 

 

Now when I try to startup JBoss, I get warnings and errors and JBoss does not startup

 

 

00:30:07,297 WARN  [org.jboss.modules] [MSC service thread 1-3] Failed to define class org.slf4j.Logger in Module "deployment.project.ear:main" from Service Module Loader: java.lang.LinkageError: loader constraint violation: loader (instance of org/jboss/modules/ModuleClassLoader) previously initiated loading for a different type with name "org/slf4j/Logger"

 

 

 

00:30:07,308 ERROR [org.jboss.msc.service.fail] [MSC service thread 1-3] MSC00001: Failed to start service jboss.deployment.subunit."project.ear"."project-services.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project.ear"."project-services.jar".POST_MODULE: Failed to process phase POST_MODULE of subdeployment "project-services.jar" of deployment "project.ear"
          at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.0.Final.jar:7.1.0.Final]
          at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
          at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
          at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
          at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
Caused by: java.lang.RuntimeException: Error getting reflective information for class com.example.project.package.api.remote.AbstractServiceLocator with ClassLoader ModuleClassLoader for Module "deployment.project.ear:main" from Service Module Loader
          at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:70) [jboss-as-server-7.1.0.Final.jar:7.1.0.Final]
          at org.jboss.as.ee.metadata.MethodAnnotationAggregator.runtimeAnnotationInformation(MethodAnnotationAggregator.java:58)
          at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.handleAnnotations(InterceptorAnnotationProcessor.java:70)
          at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:117)
          at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:54)
          at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.0.Final.jar:7.1.0.Final]
          ... 5 more
Caused by: java.lang.NoClassDefFoundError: org/slf4j/Logger
          at java.lang.Class.getDeclaredMethods0(Native Method) [rt.jar:1.6.0_29]
          at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) [rt.jar:1.6.0_29]
          at java.lang.Class.getDeclaredMethods(Class.java:1791) [rt.jar:1.6.0_29]
          at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:65) [jboss-as-server-7.1.0.Final.jar:7.1.0.Final]
          at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:66) [jboss-as-server-7.1.0.Final.jar:7.1.0.Final]
          ... 10 more
Caused by: java.lang.ClassNotFoundException: org.slf4j.Logger from [Module "deployment.project.ear:main" from Service Module Loader]
          at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
          at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
          at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
          at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
          at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
          at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
          ... 15 more

 

 

I have the necessary slf4j jars included in my ear, and this is all working fine in CR1b.

  • 1. Re: Logging with slf4j in 7.1.0.Final
    David Lloyd Master

    Let me answer the main question first before I address the finer points: yes you can provide your own logging if you want.

     

    I do want to point out that you are incorrect about a couple points.  First, the JBoss LogManager isn't so much based on JUL as it completely replaces it.  As it does replace log4j and provide implementations for slf4j and so on.  It does in fact support MDC, via the slf4j or log4j or jboss-logging APIs.  And it does in fact allow the usage of log4j appenders to be configured.  The basic idea is that no matter which log API you use or how you use it, all the logs are handled consistently.  This is why we replace JUL's log manager implementation - it's the only way to consistently and correctly merge JUL logs with log4j-style logs.

     

    That said it does not presently have complete support for per-deployment logging configurations, though that is forthcoming in a (not too distant) future release.

     

    Anyway, assuming you still want to go ahead with using your own logging API and implementation, you may also have to exclude "org.jboss.logging" in case you've got a secondary JAR linking against that.

  • 2. Re: Logging with slf4j in 7.1.0.Final
    Dan D Newbie

    Hi David,

     

    Regarding the use of log4j appenders, I asked this question a couple months ago in the forum and the general response I received was that I would have to create a custom appender.

    https://community.jboss.org/thread/176103

     

    The custom appenders required you to implement a JUL interface, which had no support for MDC. Maybe this has changed since then?

     

    Are there any up to date articles or discussions that demonstrate how to use a a log4j appender in conjunction with the jboss logging?

     

    Thanks,

    Dan

  • 3. Re: Logging with slf4j in 7.1.0.Final
    David Lloyd Master

    One more thing - you'll also have to repeat the exclusions for each subdeployment in an EAR.  There is an example of sorts here: https://docs.jboss.org/author/display/AS71/Developer+Guide#DeveloperGuide-JBossDeploymentStructureFile

  • 4. Re: Logging with slf4j in 7.1.0.Final
    Dan D Newbie

    I would much rather not provide my own logging if the JBoss logging system supports MDC and log4j appenders.

  • 5. Re: Logging with slf4j in 7.1.0.Final
    David Lloyd Master

    Dan D wrote:

     

    Hi David,

     

    Regarding the use of log4j appenders, I asked this question a couple months ago in the forum and the general response I received was that I would have to create a custom appender.

    https://community.jboss.org/thread/176103

     

    The custom appenders required you to implement a JUL interface, which had no support for MDC. Maybe this has changed since then?

     

    Are there any up to date articles or discussions that demonstrate how to use a a log4j appender in conjunction with the jboss logging?

     

    Thanks,

    Dan

     

    You should be able to simply specify a log4j appender as a custom handler.  The code is supposed to detect that it's a log4j appender and automatically adapt it.

     

    That said, you can also extend the "org.jboss.logmanager.ExtHandler" base class to get full capabilities for handling MDC and so on.  It does this by using our ExtLogRecord class which includes everything that log4j has that JUL is missing, including MDC.

  • 6. Re: Logging with slf4j in 7.1.0.Final
    matvei Newbie

    I've just noted when after upgrade from Jboss 7.1 CR1 to JBOSS 7.1 Final my Log4j logging doesn work any more  for me EAR test application with MDBs jat inside.

    Before I could include my log4j.xml file inside EJB jar, using jboss variable ${jboss.server.log.dir} for JBOSS related path.

    At the momen it does not work under 7.1.final at all, no files with log data anywehere inside JBOSS directory. What should I change?

  • 7. Re: Logging with slf4j in 7.1.0.Final
    Dan D Newbie

    I tried some simple cases using a log4j appender as a custom handler. It always resulted in an error because it didn't implement j.u.l.Handler. It would probably be good to post an article on how to use log4j appenders as a custom handler in the logging subsystem since JBoss only has 3 handlers built in (console, file, async).

     

    I was able to use ExtHandler and create a JMSAppender with MDC capabilities as a module. That was good enough for what I need so I can just use the jboss logging framework this way.

  • 8. Re: Logging with slf4j in 7.1.0.Final
    Tanya Ruttenberg Expert

    Add these dependencies to the org.jboss.logging module - in other words edit modules/org/jboss/logging/main/module.xml

     

    <module xmlns="urn:jboss:module:1.1" name="org.jboss.logging">
        <resources>
            <resource-root path="jboss-logging-3.1.0.GA.jar"/>
            <!-- Insert resources here -->
        </resources>

        <dependencies>
            <module name="org.jboss.logmanager"/>
            <module name="org.slf4j" />
            <module name="org.apache.log4j" />
        </dependencies>
    </module>

     

    That fixed it for me.

  • 9. Re: Logging with slf4j in 7.1.0.Final
    David Lloyd Master

    Guys, none of these steps should be necessary.  Definitely messing with the org.jboss.logging module should be avioded!  If you have a problem that is only fixed this way, please describe the problem completely in a JIRA issue at http://issues.jboss.org/browse/AS7 so we can figure out what's happening and fix it for the next release.

     

    The current expected behavior is that every deployment, no matter what log API it uses or bundles, will log to the server log without deployment modification.  Any deviation from this behavior is a bug and should be reported so we can fix it!

     

    Note that per-deployment logging configuration is a feature which we do not support yet but will support ASAP.  To work around this for now, your deployment will have to include a jboss-deployment-structure.xml which excludes our container log APIs and bundle your own versions of these.  Though like I said this will be changing very soon.  The logging system is being enhanced to recognize log4j and JUL log configuration files and to configure that deployment's logging accordingly.

  • 10. Re: Logging with slf4j in 7.1.0.Final
    Tanya Ruttenberg Expert

    Dang I thought I was getting into the spirit by contributing! :-)


    I have created a JIRA.

  • 11. Re: Logging with slf4j in 7.1.0.Final
    matvei Newbie

    Anyway, since the log4j does not really work (for me) in 7.1 final(???) I would really appreciate when anyone may give me an example how to configure logging for an EJB application using xml configuration file inside EAR file. Actually I do not cate what is hidden behind the logger (log4j or anything else), I just want to be able to log my data and to configure loggers using XML file inside EAR.

  • 12. Re: Logging with slf4j in 7.1.0.Final
    Robert Smith Newbie

    We are using 7.1.0 Thunder. If I am interpreting David's post correctly, application logging going to an application defined log file with their own archive strategy and patterns is not available via log4j.xml within deployments (wars, ears, etc).

    A couple of questions:

    Is it possible to do it via standalone.xml?

    I saw a post that it is fixed in 7.1.2. We are also using ICEfaces 3.0 which apparently is not compatible with JBoss 7.1.1 because of its use of Mojarra 2.17. Is 7.1.2 available and what version of Mojarra does it use?

  • 13. Re: Logging with slf4j in 7.1.0.Final
    David Lloyd Master

    I can answer this part:

    Robert Smith wrote:

     

    We are using 7.1.0 Thunder. If I am interpreting David's post correctly, application logging going to an application defined log file with their own archive strategy and patterns is not available via log4j.xml within deployments (wars, ears, etc).

    That is true for 7.1.0.  However it should be working in 7.1.2; if you have a log4j.xml in your deployment, then your deployment should be getting logged according to your configuration.

  • 14. Re: Logging with slf4j in 7.1.0.Final
    Robert Smith Newbie

    Thanks for the response David. We are kind of stuck until an open source version that allows application logging is available.
    We have since went forward and are using the standalone.xml configuration.

     

    We've run into what I believe is a limitation. We have a couple of applications that both share a common jar file. It would be useful for us to be able to direct the logging output to the appropriate application.

     

    I've not been able to determine how to do it using handlers and categories.

     

    I've create 2 size-rotating-file-handlers, one for each application.

    For the categories that are specific to the each application, Ive created a category that directs to the appropriate handler.

     

    Since each application includes the jar file, there doesnt appear to be a way to direct the common jars log output based on the application it is being called from.

     

    Example:

                <size-rotating-file-handler name="app1">

                    <level name="INFO"/>

                    <formatter>

                        <pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS z} %-5p [%c] %s%E%n"/>

                    </formatter>

                    <file relative-to="jboss.server.log.dir" path="app1.log"/>

                    <rotate-size value="100K"/>

                    <append value="false"/>

                </size-rotating-file-handler>

                <size-rotating-file-handler name="app2">

                    <level name="INFO"/>

                    <formatter>

                        <pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS z} %-5p [%c] %s%E%n"/>

                    </formatter>

                    <file relative-to="jboss.server.log.dir" path="app2.log"/>

                    <rotate-size value="100K"/>

                    <append value="false"/>

                </size-rotating-file-handler>

     

                <logger category="app1.package" use-parent-handlers="false">

                    <handlers>

                        <handler name="app1"/>

                    </handlers>

                </logger>

                <logger category="app2.package" use-parent-handlers="false">

                    <handlers>

                        <handler name="app2"/>

                    </handlers>

                </logger>

                <logger category="common" use-parent-handlers="false">

                    <handlers>

                        ?????

                    </handlers>

                </logger>

1 2 Previous Next