Log4j 2
  1. Log4j 2
  2. LOG4J2-373

Classloader issue in OSGi-environment

    Details

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

      OSGi R5 / R4 (Apache Felix 4.x)

      Description

      Using Log4j2 in a bundle causes following error:
      ERROR StatusLogger org.apache.logging.log4j.core.impl.Log4jContextFactory does not implement org.apache.logging.log4j.spi.LoggerContextFactory
      ERROR StatusLogger Unable to locate a logging implementation, using SimpleLogger

      printing the ClassLoaders in LogManager gives me following output:

      org.apache.logging.log4j.spi.LoggerContextFactory loaded by org.apache.logging.log4j-api [13]
      org.apache.logging.log4j.core.impl.Log4jContextFactory loaded by sun.misc.Launcher$AppClassLoader@35a16869

      We have two different ClassLoaders. That's why the implementation is not assignable. The core uses the bootstrap-classloader and the api uses the bundle-classloader.

      Workaround needed. Thx

      addendum:
      ProviderUtil.findClassLoader() returns the bootstrap-classloader but not the bundle-classloader of the log4j2-core. The log4j2-core is a fragment of the log4j2-api bundle. Thus, ProviderUtil.findClassLoader() must return the bundle-classloader of log4j2-api. This a bug for the case that log4j2-core is used as the implementation. There are other cases that will also cause problems. Further investigations are necessary.

      Workaround:
      1. check if log4j2 runs in an OSGI container.
      Bundle mybundle = org.osgi.framework.FrameworkUtil.getBundle(MyClass.this);
      2. if(mybundle != null), than get bundle-classloader of log4j2-impl.
      mybundle.adapt(BundleWiring.class).getClassLoader();

      1. log4j-api.patch
        2 kB
        Roland Weiglhofer

        Issue Links

        There are no Sub-Tasks for this issue.

          Activity

          Hide
          Roland Weiglhofer added a comment -

          works for me but is not fully tested.

          Show
          Roland Weiglhofer added a comment - works for me but is not fully tested.
          Hide
          Patrice Chalin added a comment -

          Thanks for the patch; it works for me as well.

          Show
          Patrice Chalin added a comment - Thanks for the patch; it works for me as well.
          Hide
          NiK added a comment - - edited

          Hi,
          I also see the same errors on the console.

          ERROR StatusLogger org.apache.logging.log4j.core.impl.Log4jContextFactory does not implement org.apache.logging.log4j.spi.LoggerContextFactory
          ERROR StatusLogger Unable to locate a logging implementation, using SimpleLogger

          How can I download this patch & apply? Your help is appreciated.

          I am using 2.0-beta9 version.

          <dependency>
          <groupId>org.apache.logging.log4j</groupId>
          <artifactId>log4j-core</artifactId>
          <version>$

          {log4j.version}</version>
          </dependency>

          <dependency>
          <groupId>org.apache.logging.log4j</groupId>
          <artifactId>log4j-api</artifactId>
          <version>${log4j.version}

          </version>
          </dependency>

          Show
          NiK added a comment - - edited Hi, I also see the same errors on the console. ERROR StatusLogger org.apache.logging.log4j.core.impl.Log4jContextFactory does not implement org.apache.logging.log4j.spi.LoggerContextFactory ERROR StatusLogger Unable to locate a logging implementation, using SimpleLogger How can I download this patch & apply? Your help is appreciated. I am using 2.0-beta9 version. <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> <version>$ {log4j.version}</version> </dependency> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-api</artifactId> <version>${log4j.version} </version> </dependency>
          Hide
          Matt Sicker added a comment -

          To apply the patch, download the source zip or tar.gz, download the patch file, then run patch -p1 < log4j-api.patch inside the source directory. Then you can run mvn install as per usual to put it in your local ~/.m2/ repository. Or if you've got your own internal Nexus, you can use the deploy target with your own profile (I'm not sure on the details; I'm more of a gradle guy myself).

          Show
          Matt Sicker added a comment - To apply the patch, download the source zip or tar.gz, download the patch file, then run patch -p1 < log4j-api.patch inside the source directory. Then you can run mvn install as per usual to put it in your local ~/.m2/ repository. Or if you've got your own internal Nexus, you can use the deploy target with your own profile (I'm not sure on the details; I'm more of a gradle guy myself).
          Hide
          Remko Popma added a comment -

          At the moment log4j2 users need at least log4j-api and log4j-core.

          If I understand correctly, this patch would introduce dependencies from log4j-api to org.osgi.compendium and org.osgi.core. Does that mean that all log4j2 users would need to have these 2 jars in the classpath in order to use log4j2? I would prefer a solution that does not introduce such a dependency for non-OSGi users of log4j2.

          Show
          Remko Popma added a comment - At the moment log4j2 users need at least log4j-api and log4j-core. If I understand correctly, this patch would introduce dependencies from log4j-api to org.osgi.compendium and org.osgi.core. Does that mean that all log4j2 users would need to have these 2 jars in the classpath in order to use log4j2? I would prefer a solution that does not introduce such a dependency for non-OSGi users of log4j2.
          Hide
          Matt Sicker added a comment -

          Shouldn't you be loading core as a bundle too?

          Show
          Matt Sicker added a comment - Shouldn't you be loading core as a bundle too?
          Hide
          Ralph Goers added a comment -

          In core the osgi core jar is marked as provided since it would be expected to already be present in an OSGi environment. I would expect the same should be done for these dependencies. However, in core that code path will only execute if a bundleresource url is encountered. In this case it seems like it will invoke the OSGi framework for everything which clearly isn't OK. The patch should be reworked to detect if an OSGi environment is present (i.e. - detect if the FrameworkUtil class is present) before attempting to call it.

          Show
          Ralph Goers added a comment - In core the osgi core jar is marked as provided since it would be expected to already be present in an OSGi environment. I would expect the same should be done for these dependencies. However, in core that code path will only execute if a bundleresource url is encountered. In this case it seems like it will invoke the OSGi framework for everything which clearly isn't OK. The patch should be reworked to detect if an OSGi environment is present (i.e. - detect if the FrameworkUtil class is present) before attempting to call it.
          Hide
          Matt Sicker added a comment -

          I meant log4j-core, not osgi.

          Show
          Matt Sicker added a comment - I meant log4j-core, not osgi.
          Hide
          Matt Sicker added a comment -

          Shouldn't you be loading the bundles like so: log4j-api is the host bundle, and then use the OSGi bundles from there. Log4j-api should be using its own class loader in this case.

          I've got some ideas on how to approach this in an API modification, but I'll have to flesh them out first.

          Show
          Matt Sicker added a comment - Shouldn't you be loading the bundles like so: log4j-api is the host bundle, and then use the OSGi bundles from there. Log4j-api should be using its own class loader in this case. I've got some ideas on how to approach this in an API modification, but I'll have to flesh them out first.
          Hide
          Norval Hope added a comment -

          Just wanted to add a note that this is not purely an OSGi issue and also broke unit tests we were running using the maven surefire plugin. Given this is probably a pretty common use case you make want to consider including the patch in your next rc / release.

          Thanks

          Show
          Norval Hope added a comment - Just wanted to add a note that this is not purely an OSGi issue and also broke unit tests we were running using the maven surefire plugin. Given this is probably a pretty common use case you make want to consider including the patch in your next rc / release. Thanks
          Hide
          Remko Popma added a comment - - edited

          Norval, it may be a good idea to raise the problem you are experiencing in a separate Jira ticket and link to this ticket.

          That way you can provide more detail about the problem you are seeing (stack trace, perhaps source code for a failing unit test or some other way for us to reproduce the issue) by attaching to that ticket.

          It is possible that the underlying cause is the same but it is difficult to tell at the moment.

          EDIT:
          Or did you mean that you have a unit test that fails with trunk but passes after applying the patch that is attached to this Jira? I think that would be useful!

          Show
          Remko Popma added a comment - - edited Norval, it may be a good idea to raise the problem you are experiencing in a separate Jira ticket and link to this ticket. That way you can provide more detail about the problem you are seeing (stack trace, perhaps source code for a failing unit test or some other way for us to reproduce the issue) by attaching to that ticket. It is possible that the underlying cause is the same but it is difficult to tell at the moment. EDIT: Or did you mean that you have a unit test that fails with trunk but passes after applying the patch that is attached to this Jira? I think that would be useful!
          Hide
          Matt Sicker added a comment -

          The patch provided is not realistic since it adds OSGi dependencies to the API. I have a better solution that involves pulling out the static initialization in LogManager into its own class. That way, the OSGi bundles can register the correct class loader when they get loaded.

          Show
          Matt Sicker added a comment - The patch provided is not realistic since it adds OSGi dependencies to the API. I have a better solution that involves pulling out the static initialization in LogManager into its own class. That way, the OSGi bundles can register the correct class loader when they get loaded.
          Hide
          Remko Popma added a comment -

          Matt, you mentioned that what you have in mind may require API changes.

          I think previously we were thinking to work on OSGi after the 2.0 GA release, but if proper OSGi support requires API changes then perhaps we should make these changes before the 2.0 GA release.

          Could you clarify what you have in mind for the API changes you mentioned, or perhaps provide a patch?

          Show
          Remko Popma added a comment - Matt, you mentioned that what you have in mind may require API changes. I think previously we were thinking to work on OSGi after the 2.0 GA release, but if proper OSGi support requires API changes then perhaps we should make these changes before the 2.0 GA release. Could you clarify what you have in mind for the API changes you mentioned, or perhaps provide a patch?
          Hide
          Matt Sicker added a comment -

          Oh wow, never mind. I found a super simple fix for this. The API change that I mean is an OSGi API change. It would be preferable to have them match with the project version to some degree. There may be a need to automate an API change analyzer to enforce proper version numbering in the bundle.

          Show
          Matt Sicker added a comment - Oh wow, never mind. I found a super simple fix for this. The API change that I mean is an OSGi API change. It would be preferable to have them match with the project version to some degree. There may be a need to automate an API change analyzer to enforce proper version numbering in the bundle.
          Hide
          Matt Sicker added a comment -

          Wait, scratch that, the core-reduced bundle shouldn't be the one exporting the log4j API. Let me rework that a little bit.

          Show
          Matt Sicker added a comment - Wait, scratch that, the core-reduced bundle shouldn't be the one exporting the log4j API. Let me rework that a little bit.
          Hide
          Matt Sicker added a comment -

          I'm looking into this bug right now. In the meantime, let me clarify that most of the API changes that would be useful for bundles would be focused in the log4j-core package structure. If that API can change in 2.x version upgrades, then that won't be a problem. We'd be able to get a nice modular OSGi version of core to really make it useful. This might also offer an alternative to the "fat" JARs like log4j-core.

          Show
          Matt Sicker added a comment - I'm looking into this bug right now. In the meantime, let me clarify that most of the API changes that would be useful for bundles would be focused in the log4j-core package structure. If that API can change in 2.x version upgrades, then that won't be a problem. We'd be able to get a nice modular OSGi version of core to really make it useful. This might also offer an alternative to the "fat" JARs like log4j-core.
          Hide
          Remko Popma added a comment -

          I see. Personally, if changes to log4j-core are necessary, I would prefer to make them before the 2.0 GA release.

          Are you suggesting to split up the log4j-core jar? Hopefully that would only result in many small jars for OSGi users, and non-OSGi users can continue to use the single log4j-core jar that exists currently, does that match what you have in mind?

          Show
          Remko Popma added a comment - I see. Personally, if changes to log4j-core are necessary, I would prefer to make them before the 2.0 GA release. Are you suggesting to split up the log4j-core jar? Hopefully that would only result in many small jars for OSGi users, and non-OSGi users can continue to use the single log4j-core jar that exists currently, does that match what you have in mind?
          Hide
          Christophe Bordier added a comment -

          I'm surprised that nobody uploaded a correct jar with the patch applied. Here it is. I called it "RC 2" but please note that this is NOT an official release ! https://drive.google.com/file/d/0B-wGewYKm47hRjA4U2E1eFA2Q2s/edit?usp=sharing

          Show
          Christophe Bordier added a comment - I'm surprised that nobody uploaded a correct jar with the patch applied. Here it is. I called it "RC 2" but please note that this is NOT an official release ! https://drive.google.com/file/d/0B-wGewYKm47hRjA4U2E1eFA2Q2s/edit?usp=sharing
          Hide
          Matt Sicker added a comment -

          This issue may be solved with the recent OSGi updates. I'll follow up later with the results of my own testing, but in theory, this should work now.

          Show
          Matt Sicker added a comment - This issue may be solved with the recent OSGi updates. I'll follow up later with the results of my own testing, but in theory, this should work now.
          Hide
          Matt Sicker added a comment -

          Fixed in revision 1612002. Please verify and close.

          Show
          Matt Sicker added a comment - Fixed in revision 1612002. Please verify and close.
          Hide
          Snehadeep Sethia added a comment -

          I'm get the following message on an OSGi project. "ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console...", I'm using log4j-api v2.0.2 and log4j-core v2.0.2; The logger works very well on a stand alone java project but fails on an eclipse project. Any pointers?

          Show
          Snehadeep Sethia added a comment - I'm get the following message on an OSGi project. "ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console...", I'm using log4j-api v2.0.2 and log4j-core v2.0.2; The logger works very well on a stand alone java project but fails on an eclipse project. Any pointers?
          Hide
          Matt Sicker added a comment -

          I think I found a race condition between the bundle activator and LogManager. I've fixed this in the master branch. Could you try out the latest git version?

          Show
          Matt Sicker added a comment - I think I found a race condition between the bundle activator and LogManager. I've fixed this in the master branch. Could you try out the latest git version?
          Hide
          Snehadeep Sethia added a comment - - edited

          I get Compilation errors on the log4j-api project

          [ERROR] COMPILATION ERROR :
          [INFO] -------------------------------------------------------------
          [ERROR] c:\Users\SD\Desktop\log4j master\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\message\LocalizedMessageTest.java:[36,45] type parameters of <T>T cannot be determi
          ned; no unique maximal instance exists for type variable T with upper bounds T,java.lang.Object
          [INFO] 1 error

          for the time being I've commented the test and proceed with mvn clean install on the project.
          I checked out master from here https://github.com/apache/logging-log4j2.git

          I still don't see the issue being resolved. I still get the same error (I verified that the jars in the class path were log4j-api-2.1-SNAPSHOT and log4j-core-2.1-SNAPSHOT)
          Matt Sicker I see the pom version as 2.1-SNAPSHOT, did you fix it on 2.0.1 or 2.0.2?

          Show
          Snehadeep Sethia added a comment - - edited I get Compilation errors on the log4j-api project [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] c:\Users\SD\Desktop\log4j master\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\message\LocalizedMessageTest.java: [36,45] type parameters of <T>T cannot be determi ned; no unique maximal instance exists for type variable T with upper bounds T,java.lang.Object [INFO] 1 error for the time being I've commented the test and proceed with mvn clean install on the project. I checked out master from here https://github.com/apache/logging-log4j2.git I still don't see the issue being resolved. I still get the same error (I verified that the jars in the class path were log4j-api-2.1-SNAPSHOT and log4j-core-2.1-SNAPSHOT) Matt Sicker I see the pom version as 2.1-SNAPSHOT, did you fix it on 2.0.1 or 2.0.2?
          Hide
          Gary Gregory added a comment -

          Make sure you have the latest Java 6 JDK (or Java 7)

          Gary

          Show
          Gary Gregory added a comment - Make sure you have the latest Java 6 JDK (or Java 7) Gary
          Hide
          Matt Sicker added a comment -

          The race condition part was fixed in 2.1-SNAPSHOT. The general ClassLoader issue was fixed in 2.0.1 to some extent. There's still probably more issues to work out, but the main showstoppers seem to be all fixed.

          Show
          Matt Sicker added a comment - The race condition part was fixed in 2.1-SNAPSHOT. The general ClassLoader issue was fixed in 2.0.1 to some extent. There's still probably more issues to work out, but the main showstoppers seem to be all fixed.
          Hide
          Snehadeep Sethia added a comment - - edited

          I'm on Java6u45, I built the 2.1-SNAPSHOT and still see the same issue on all 3 versions (2.1-SNAPSHOT, 2.0.1 and 2.0.2).

          Should the manifest have something specific that I'm missing? Can you point me to a sample plugin project that seems to work for you Matt Sicker.

          Show
          Snehadeep Sethia added a comment - - edited I'm on Java6u45, I built the 2.1-SNAPSHOT and still see the same issue on all 3 versions (2.1-SNAPSHOT, 2.0.1 and 2.0.2). Should the manifest have something specific that I'm missing? Can you point me to a sample plugin project that seems to work for you Matt Sicker .
          Hide
          Matt Sicker added a comment -

          Are you using any custom plugins? Or is this purely log4j-api and log4j-core?

          Show
          Matt Sicker added a comment - Are you using any custom plugins? Or is this purely log4j-api and log4j-core?
          Hide
          Snehadeep Sethia added a comment - - edited

          The plugin has a few other dependencies including junit and powermock. The product has a lot of custom plugins.

          Show
          Snehadeep Sethia added a comment - - edited The plugin has a few other dependencies including junit and powermock. The product has a lot of custom plugins.
          Hide
          Matt Sicker added a comment -

          I mean custom Log4j plugins.

          Show
          Matt Sicker added a comment - I mean custom Log4j plugins.
          Hide
          Snehadeep Sethia added a comment -

          none except log4j-api and log4j-core

          Show
          Snehadeep Sethia added a comment - none except log4j-api and log4j-core
          Hide
          Gary Gregory added a comment -

          I am sorry you are having trouble.

          Here, I was able to run mvn clean compile OK using:

          mvn -version
          
          Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T16:58:10-04:00)
          Maven home: C:\Java\apache-maven-3.2.3
          Java version: 1.6.0_45, vendor: Sun Microsystems Inc.
          Java home: C:\Program Files\Java\jdk1.6.0_45\jre
          Default locale: en_US, platform encoding: Cp1252
          OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
          
          Show
          Gary Gregory added a comment - I am sorry you are having trouble. Here, I was able to run mvn clean compile OK using: mvn -version Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T16:58:10-04:00) Maven home: C:\Java\apache-maven-3.2.3 Java version: 1.6.0_45, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_45\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
          Hide
          Gary Gregory added a comment - - edited

          Just to make sure the obvious has been taken care of: you ran "mvn clean install" to put the 2.1-SNAPSHOT in your local repo? Or, are you putting the jar files on your classpath differently?

          Show
          Gary Gregory added a comment - - edited Just to make sure the obvious has been taken care of: you ran "mvn clean install" to put the 2.1-SNAPSHOT in your local repo? Or, are you putting the jar files on your classpath differently?
          Hide
          Snehadeep Sethia added a comment -

          I ran "mvn clean install" to install it to my local m2 repo. The issue building 2.1-SNAPSHOT was maven version, I was using 2.2.1 and later switched to 3.1.0 and it seems to install fine.

          Step taken so far
          1. Ran mvn clean install on log4j-api and log4j-core cloned from https://github.com/apache/logging-log4j2.git and git checkout master
          2. Ran "mvn eclipse:eclipse -DdownloadSources=true -Declipse.useProjectReferences=false -DdownloadJavadocs=true -U" on the plugin whose pom.xml has log4j-api and log4j-core as dependencies
          3. Ram mvn copyresource to generate MANIFEST.MF on the plugin project
          4. Ran "mvn eclipse:eclipse -DdownloadSources=true -Declipse.useProjectReferences=false -DdownloadJavadocs=true -U" on the main product
          5. Ran "mvn clean install" on the main product
          6. Ran the main product and get the exception "ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console..."

          I'm using
          jdk1.6.0_45 (32 bit)
          maven 3 to build the log4j jars
          maven 2 to build the plugin and the product (we have a maven 2 constraint on the product)
          org.eclipse.osgi version "3.8.1-SDK-4.2.1"

          Show
          Snehadeep Sethia added a comment - I ran "mvn clean install" to install it to my local m2 repo. The issue building 2.1-SNAPSHOT was maven version, I was using 2.2.1 and later switched to 3.1.0 and it seems to install fine. Step taken so far 1. Ran mvn clean install on log4j-api and log4j-core cloned from https://github.com/apache/logging-log4j2.git and git checkout master 2. Ran "mvn eclipse:eclipse -DdownloadSources=true -Declipse.useProjectReferences=false -DdownloadJavadocs=true -U" on the plugin whose pom.xml has log4j-api and log4j-core as dependencies 3. Ram mvn copyresource to generate MANIFEST.MF on the plugin project 4. Ran "mvn eclipse:eclipse -DdownloadSources=true -Declipse.useProjectReferences=false -DdownloadJavadocs=true -U" on the main product 5. Ran "mvn clean install" on the main product 6. Ran the main product and get the exception "ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console..." I'm using jdk1.6.0_45 (32 bit) maven 3 to build the log4j jars maven 2 to build the plugin and the product (we have a maven 2 constraint on the product) org.eclipse.osgi version "3.8.1-SDK-4.2.1"
          Hide
          Matt Sicker added a comment -

          Could you check out the latest code from here: http://git-wip-us.apache.org/repos/asf/logging-log4j2.git

          And check out the branch called LOG4J2-809. I've been working on some ClassLoader-related code there which might affect this issue.

          Show
          Matt Sicker added a comment - Could you check out the latest code from here: http://git-wip-us.apache.org/repos/asf/logging-log4j2.git And check out the branch called LOG4J2-809 . I've been working on some ClassLoader-related code there which might affect this issue.
          Hide
          Snehadeep Sethia added a comment -

          I tried branch LOG4J2-809 from the link mentioned above, but still get the same issue.
          A few things to note are the versions that I'm using, I'm not sure if these are conflicting/causing the trouble.

          <org.osgi.core>4.3.1</org.osgi.core>
          <org.eclipse.osgi.services>3.3.100-SDK-4.2.1</org.eclipse.osgi.services>
          <org.eclipse.osgi>3.8.1-SDK-4.2.1</org.eclipse.osgi>

          Show
          Snehadeep Sethia added a comment - I tried branch LOG4J2-809 from the link mentioned above, but still get the same issue. A few things to note are the versions that I'm using, I'm not sure if these are conflicting/causing the trouble. <org.osgi.core>4.3.1</org.osgi.core> <org.eclipse.osgi.services>3.3.100-SDK-4.2.1</org.eclipse.osgi.services> <org.eclipse.osgi>3.8.1-SDK-4.2.1</org.eclipse.osgi>
          Hide
          Honey Goyal added a comment -

          Is it really resolved? In Karaf 3.0.3, i am getting the same error "ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console..."

          As karaf 3.0.3 comes with pax logging version 1.8.1(which support log4j2). I installed bundles log4j-api(2.1) and log4j-core(2.1) manually in karaf.

          Any workaround?

          Show
          Honey Goyal added a comment - Is it really resolved? In Karaf 3.0.3, i am getting the same error "ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console..." As karaf 3.0.3 comes with pax logging version 1.8.1(which support log4j2). I installed bundles log4j-api(2.1) and log4j-core(2.1) manually in karaf. Any workaround?
          Hide
          Honey Goyal added a comment -

          I checked LoaderUtil.java's static block, I found below class loader in karaf runtime container.

          [sun.misc.Launcher$AppClassLoader@f4b2263, org.apache.logging.log4j.api [65], sun.misc.Launcher$AppClassLoader@f4b2263]
          

          It tried to find

          META-INF/log4j-provider.properties

          file in resources, which it not able to found. That's why this

          ProviderUtil.hasProviders()

          returns false.
          I am using log4j-api 2.1 and log4j-core 2.1. Both bundles i have installed in karaf container.

          Any suggestions?

          Show
          Honey Goyal added a comment - I checked LoaderUtil.java's static block, I found below class loader in karaf runtime container. [sun.misc.Launcher$AppClassLoader@f4b2263, org.apache.logging.log4j.api [65], sun.misc.Launcher$AppClassLoader@f4b2263] It tried to find META-INF/log4j-provider.properties file in resources, which it not able to found. That's why this ProviderUtil.hasProviders() returns false. I am using log4j-api 2.1 and log4j-core 2.1. Both bundles i have installed in karaf container. Any suggestions?

            People

            • Assignee:
              Matt Sicker
              Reporter:
              Roland Weiglhofer
            • Votes:
              2 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development