Log4j 2
  1. Log4j 2
  2. LOG4J2-666

Ability to use a custom MBean domain

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-rc1, 2.0-rc2
    • Fix Version/s: 2.0
    • Component/s: JMX
    • Labels:
      None

      Description

      I have a few webapps codeployed in the same JVM. I'd like to use log4j 2 for all of them but there is a clash in log4j MBeans since they have a fixed domain . Could we support customizing the domain for log4j MBeans? I'd like to set a different one for each webapp.

      Thanks,
      Te

        Issue Links

          Activity

          Hide
          Te L added a comment - - edited

          "ConfigLocationUri" is an attribute of the log4j2 MBean. It's got a wrong value there.

          I am still not sure how to set the context name. Can we provide an easy way to do that perhaps via the config file?

          After using AsyncRoot and AsyncLogger, the MBean name becomes weird:
          (with standalone tomcat):
          org.apache.logging.log4j2:type="WebappClassLoader\n context: /hello-world\n delegate: false\n repositories:\n /WEB-INF/classes/\n----------> Parent Classloader:\norg.apache.catalina.loader.StandardClassLoader@892949f\n"
          (with tomcat maven plugin):
          org.apache.logging.log4j2:type="WebappClassLoader\n context: \n delegate: false\n repositories:\n----------> Parent Classloader:\nClassRealm[plugin>org.apache.tomcat.maven:tomcat7-maven-plugin:2.2, parent: sun.misc.Launcher$AppClassLoader@7d487b8b]\n"

          How do I verify the fix? Is there a snapshot build I can download or something?

          Show
          Te L added a comment - - edited "ConfigLocationUri" is an attribute of the log4j2 MBean. It's got a wrong value there. I am still not sure how to set the context name. Can we provide an easy way to do that perhaps via the config file? After using AsyncRoot and AsyncLogger, the MBean name becomes weird: (with standalone tomcat): org.apache.logging.log4j2:type="WebappClassLoader\n context: /hello-world\n delegate: false\n repositories:\n /WEB-INF/classes/\n----------> Parent Classloader:\norg.apache.catalina.loader.StandardClassLoader@892949f\n" (with tomcat maven plugin): org.apache.logging.log4j2:type="WebappClassLoader\n context: \n delegate: false\n repositories:\n----------> Parent Classloader:\nClassRealm [plugin>org.apache.tomcat.maven:tomcat7-maven-plugin:2.2, parent: sun.misc.Launcher$AppClassLoader@7d487b8b] \n" How do I verify the fix? Is there a snapshot build I can download or something?
          Hide
          Remko Popma added a comment -

          Fixed in revision 1608149.

          MBean names should now be unique for different web applications even when using Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector.
          Please be aware that making all loggers async only works correctly with web applications if you bundle the log4j2 jar files in WEB-INF/lib in your war file. (See LOG4J2-493).

          Please verify and close.

          Show
          Remko Popma added a comment - Fixed in revision 1608149. MBean names should now be unique for different web applications even when using Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector . Please be aware that making all loggers async only works correctly with web applications if you bundle the log4j2 jar files in WEB-INF/lib in your war file. (See LOG4J2-493 ). Please verify and close.
          Hide
          Remko Popma added a comment -

          ... I don't know what you mean by "ConfigLocationUri attribute points to a wrong location for the log4j2.json".

          It looks like your log4j2.json file is located under src/main/resources so I would expect it gets bundled in your application's jar file and there is no need to specify a location to tell log4j2 where to find this file...

          Also, I could not find "ConfigLocationUri" anywhere in your sample project. Where are you seeing this? What is the actual value? What is the expected value?

          Show
          Remko Popma added a comment - ... I don't know what you mean by "ConfigLocationUri attribute points to a wrong location for the log4j2.json". It looks like your log4j2.json file is located under src/main/resources so I would expect it gets bundled in your application's jar file and there is no need to specify a location to tell log4j2 where to find this file... Also, I could not find "ConfigLocationUri" anywhere in your sample project. Where are you seeing this? What is the actual value? What is the expected value?
          Hide
          Remko Popma added a comment -

          Okay, I understand the issue now.

          Yes, if all loggers are made asynchronous by setting Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector, the loggerContext name is "AsyncLoggerContext" for all web apps. This name is set in the AsyncLoggerContextSelector class.

          We can make this name unique by appending the hashCode of the AsyncLoggerContextSelector class. I believe that should resolve the issue.

          As a side note: please be aware that making all loggers async only works correctly with web applications if you bundle the log4j2 jar files in WEB-INF/lib in your war file. (See LOG4J2-493).

          Meanwhile, the quickest way for you to resolve this is to configure log4j2 differently:

          • remove the Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector setting
          • and, in your log4j2.json configuration, use AsyncRoot and AsyncLogger instead of Root and Logger. This also makes the loggers asynchronous, giving you the same performance benefits, but uses a different mechanism under the hood. This way, the LoggerContext will be assigned a unique name by the web container.

          I'm beginning to think we should update the documentation to recommend that web applications should avoid the use of Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector and instead configure with AsyncRoot and AsyncLogger to avoid these issues...

          Show
          Remko Popma added a comment - Okay, I understand the issue now. Yes, if all loggers are made asynchronous by setting Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector , the loggerContext name is "AsyncLoggerContext" for all web apps. This name is set in the AsyncLoggerContextSelector class. We can make this name unique by appending the hashCode of the AsyncLoggerContextSelector class. I believe that should resolve the issue. As a side note: please be aware that making all loggers async only works correctly with web applications if you bundle the log4j2 jar files in WEB-INF/lib in your war file. (See LOG4J2-493 ). Meanwhile, the quickest way for you to resolve this is to configure log4j2 differently: remove the Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector setting and, in your log4j2.json configuration, use AsyncRoot and AsyncLogger instead of Root and Logger . This also makes the loggers asynchronous, giving you the same performance benefits, but uses a different mechanism under the hood. This way, the LoggerContext will be assigned a unique name by the web container. I'm beginning to think we should update the documentation to recommend that web applications should avoid the use of Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector and instead configure with AsyncRoot and AsyncLogger to avoid these issues...
          Hide
          Te L added a comment -

          I didn't get a chance to work on this until now. Please unzip the attached file and run "mvn tomcat7:run". The log file is at target/tomcat/logs/service.log.

          You can start a jconsole to see the MBeans.

          There are two issues here:

          • The MBean name is not unique: org.apache.logging.log4j2:type=AsyncLoggerContext
          • ConfigLocationUri attribute points to a wrong location for the log4j2.json
          Show
          Te L added a comment - I didn't get a chance to work on this until now. Please unzip the attached file and run "mvn tomcat7:run". The log file is at target/tomcat/logs/service.log. You can start a jconsole to see the MBeans. There are two issues here: The MBean name is not unique: org.apache.logging.log4j2:type=AsyncLoggerContext ConfigLocationUri attribute points to a wrong location for the log4j2.json
          Hide
          Remko Popma added a comment -

          I did a quick search for "servlet 3 Java-based bootstrap" and got a lot of Spring-related results. I'm not confident I can reproduce the issue without more detail. Can you provide a small web app that demonstrates the issue?

          Show
          Remko Popma added a comment - I did a quick search for "servlet 3 Java-based bootstrap" and got a lot of Spring-related results. I'm not confident I can reproduce the issue without more detail. Can you provide a small web app that demonstrates the issue?
          Hide
          Te L added a comment -

          I was using tomcat 7.0.52.

          Show
          Te L added a comment - I was using tomcat 7.0.52.
          Hide
          Remko Popma added a comment -

          Let me check. If I want to reproduce the issue, which web container/version should I use?

          Show
          Remko Popma added a comment - Let me check. If I want to reproduce the issue, which web container/version should I use?
          Hide
          Te L added a comment -

          I'm not sure if log4j2 is not behaving as you described or if my webapp doesn't have a context name. How is the context name set? My webapp doesn't use web.xml but servlet 3 Java-based bootstrapping.

          Show
          Te L added a comment - I'm not sure if log4j2 is not behaving as you described or if my webapp doesn't have a context name. How is the context name set? My webapp doesn't use web.xml but servlet 3 Java-based bootstrapping.
          Hide
          Remko Popma added a comment -

          Did you have a chance to take a look at my questions? I believe that every Log4J2 MBean has a unique name, because each web app has a unique context name. Am I mistaken?

          Show
          Remko Popma added a comment - Did you have a chance to take a look at my questions? I believe that every Log4J2 MBean has a unique name, because each web app has a unique context name. Am I mistaken?
          Hide
          Remko Popma added a comment -

          I think this was addressed with LOG4J2-500 in release rc1.
          Each MBean name contains the logger context name. If you have multiple web apps, their logger context should be unique and therefore the MBean names should not clash.

          Which web container are you using? Are you seeing the same LoggerContext name for different web apps?

          Show
          Remko Popma added a comment - I think this was addressed with LOG4J2-500 in release rc1. Each MBean name contains the logger context name. If you have multiple web apps, their logger context should be unique and therefore the MBean names should not clash. Which web container are you using? Are you seeing the same LoggerContext name for different web apps?

            People

            • Assignee:
              Remko Popma
              Reporter:
              Te L
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development