Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0-beta9
    • Fix Version/s: 2.0-rc1, 2.0
    • Component/s: Core
    • Labels:
      None
    • Environment:

      OSGi R5 / R4 (Apache Felix 4.x)

      Description

      NPE in Log4j2-core during shutdown.

      g! Exception in thread "Thread-2" java.lang.NullPointerException
      at org.apache.felix.framework.BundleWiringImpl.diagnoseClassLoadError(BundleWiringImpl.java:2625)
      at org.apache.felix.framework.BundleWiringImpl.access$700(BundleWiringImpl.java:75)
      at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1967)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
      at org.apache.logging.log4j.core.LoggerContext.stop(LoggerContext.java:210)
      at org.apache.logging.log4j.core.LoggerContext$ShutdownThread.run(LoggerContext.java:437)
      Exception in thread "Thread-6" java.lang.NullPointerException
      at org.apache.felix.framework.BundleWiringImpl.diagnoseClassLoadError(BundleWiringImpl.java:2625)
      at org.apache.felix.framework.BundleWiringImpl.access$700(BundleWiringImpl.java:75)
      at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1967)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
      at org.apache.logging.log4j.core.LoggerContext.stop(LoggerContext.java:210)
      at org.apache.logging.log4j.core.LoggerContext$ShutdownThread.run(LoggerContext.java:437)

      It's a ClassLoader-issue. I guess that log4j2-core uses the bootstrap-classloader but not the bundle-classloaer.

        Issue Links

          Activity

          Hide
          Remko Popma added a comment -

          Applied the fix described in the comments and the patch.
          I haven't been able to test this yet, but the change seems benign so I went ahead.

          Fixed in revision 1555633.
          Please verify and close.

          Show
          Remko Popma added a comment - Applied the fix described in the comments and the patch. I haven't been able to test this yet, but the change seems benign so I went ahead. Fixed in revision 1555633. Please verify and close.
          Hide
          Matt Sicker added a comment -

          This should fix this bug. The main idea is to load NullConfiguration as soon as possible so that during shutdown we'll still have an instance to use regardless of classpath.

          Show
          Matt Sicker added a comment - This should fix this bug. The main idea is to load NullConfiguration as soon as possible so that during shutdown we'll still have an instance to use regardless of classpath.
          Hide
          Roland Weiglhofer added a comment -

          Hello Ralph,
          I added the NullConfiguration to my BundleActivator-class as you suggested.

          private static Configuration logconfig = new NullConfiguration();

          @Override
          public void stop(BundleContext context) throws Exception

          { ... LoggerContext logcontext = (LoggerContext) LogManager.getContext(); logcontext.updateLoggers(logconfig); }

          I tested it and it works now. But it is just a workaround.

          Show
          Roland Weiglhofer added a comment - Hello Ralph, I added the NullConfiguration to my BundleActivator-class as you suggested. private static Configuration logconfig = new NullConfiguration(); @Override public void stop(BundleContext context) throws Exception { ... LoggerContext logcontext = (LoggerContext) LogManager.getContext(); logcontext.updateLoggers(logconfig); } I tested it and it works now. But it is just a workaround.
          Hide
          Ralph Goers added a comment -

          I'm not sure what is going on there but the easy way to address this would be to declare a static Configuration in LoggerContext that is set to a NullConfiguration. Then during stop instead of doing a new just set the configuration to point to the static NullConfiguration.

          Is it possible you could give that a try and see if it solves the problem?

          Show
          Ralph Goers added a comment - I'm not sure what is going on there but the easy way to address this would be to declare a static Configuration in LoggerContext that is set to a NullConfiguration. Then during stop instead of doing a new just set the configuration to point to the static NullConfiguration. Is it possible you could give that a try and see if it solves the problem?
          Hide
          Roland Weiglhofer added a comment -

          I have seen the issue again in my logfiles. But this time with a slightly different trace.

          This sounds very interesting:
          Caused by: java.lang.ClassNotFoundException: Unable to load class 'org.apache.logging.log4j.core.config.NullConfiguration' Because The bundle wiring for org.apache.logging.log4j api is no longer valid.
          Wires are between resolved dependent bundles. If one bundle is stopped the wire is invalid. The OSGi-container stopps bundles in order of their dependencies. Could it be that some dependency-definitions are missing in the POMs? Could it be that the core holds an unreleased zombie-instance of a classloader and tries to instanciate something which is no longer in the classpath because the provider bundle is stopped? I don't know what is going on, but thinking out loud.

          g! Exception in thread "Thread-6" java.lang.NoClassDefFoundError: org/apache/logging/log4j/core/config/NullConfiguration
          at org.apache.logging.log4j.core.LoggerContext.stop(LoggerContext.java:210)
          at org.apache.logging.log4j.core.LoggerContext$ShutdownThread.run(LoggerContext.java:437)
          Caused by: java.lang.ClassNotFoundException: Unable to load class 'org.apache.logging.log4j.core.config.NullConfiguration' because the bundle wiring for org.apache.logging.log4j-api is no longer valid.
          at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1494)
          at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
          at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
          ... 2 more
          Exception in thread "Thread-2" java.lang.NoClassDefFoundError: org/apache/logging/log4j/core/config/NullConfiguration
          at org.apache.logging.log4j.core.LoggerContext.stop(LoggerContext.java:210)
          at org.apache.logging.log4j.core.LoggerContext$ShutdownThread.run(LoggerContext.java:437)

          Show
          Roland Weiglhofer added a comment - I have seen the issue again in my logfiles. But this time with a slightly different trace. This sounds very interesting: Caused by: java.lang.ClassNotFoundException: Unable to load class 'org.apache.logging.log4j.core.config.NullConfiguration' Because The bundle wiring for org.apache.logging.log4j api is no longer valid. Wires are between resolved dependent bundles. If one bundle is stopped the wire is invalid. The OSGi-container stopps bundles in order of their dependencies. Could it be that some dependency-definitions are missing in the POMs? Could it be that the core holds an unreleased zombie-instance of a classloader and tries to instanciate something which is no longer in the classpath because the provider bundle is stopped? I don't know what is going on, but thinking out loud. g! Exception in thread "Thread-6" java.lang.NoClassDefFoundError: org/apache/logging/log4j/core/config/NullConfiguration at org.apache.logging.log4j.core.LoggerContext.stop(LoggerContext.java:210) at org.apache.logging.log4j.core.LoggerContext$ShutdownThread.run(LoggerContext.java:437) Caused by: java.lang.ClassNotFoundException: Unable to load class 'org.apache.logging.log4j.core.config.NullConfiguration' because the bundle wiring for org.apache.logging.log4j-api is no longer valid. at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1494) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ... 2 more Exception in thread "Thread-2" java.lang.NoClassDefFoundError: org/apache/logging/log4j/core/config/NullConfiguration at org.apache.logging.log4j.core.LoggerContext.stop(LoggerContext.java:210) at org.apache.logging.log4j.core.LoggerContext$ShutdownThread.run(LoggerContext.java:437)
          Hide
          Roland Weiglhofer added a comment -

          (Addendum: Null-checks are required because the bootstrap classloader is often defined as null. See javadoc for getClassLoader() )

          Show
          Roland Weiglhofer added a comment - (Addendum: Null-checks are required because the bootstrap classloader is often defined as null. See javadoc for getClassLoader() )
          Hide
          Roland Weiglhofer added a comment -

          ... or the class loader is not checked for null (e.g. in the LogManager line 59).

          Show
          Roland Weiglhofer added a comment - ... or the class loader is not checked for null (e.g. in the LogManager line 59).

            People

            • Assignee:
              Unassigned
              Reporter:
              Roland Weiglhofer
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development