Log4j 2
  1. Log4j 2
  2. LOG4J2-346

Cyclic dependency in OSGi-context. Apache Log4j SLF4J Binding <-> slf4j-api

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.0-beta4, 2.0-beta8, 2.0-beta9, 2.0-rc1
    • Fix Version/s: 2.0-rc2
    • Component/s: Core, SLF4J Bridge
    • Labels:
    • Environment:

      OSGi R5 / Apache Felix 4.x

      Description

      The bundle "Apache Log4j SLF4J Binding" (2.0.0.beta8) has an unresolved dependency to the package org.slf4j which is exported by the slf4j-api bundle. The Slf4j-api bundle has also an unresolved dependency to the package org.slf4j.impl which is exported by the bundle "Apache Log4j SLF4J Binding". Without the slf4j-api everything works. But the Slf4j-api bundle is needed because of given dependencies of third-party-bundles. The "Apache Log4j SLF4J Binding" bundle should also export the package org.slf4j.

      ----------------------------------------------------------------

      ID|State |Level|Name
      0|Active | 0|System Bundle (4.2.1)
      4|Active | 2|Apache Felix Bundle Repository (1.6.6)
      5|Active | 2|Apache Felix Configuration Admin Service (1.6.0)
      6|Active | 2|Apache Felix Gogo Command (0.12.0)
      7|Active | 2|Apache Felix Gogo Runtime (0.10.0)
      8|Active | 2|Apache Felix Gogo Shell (0.10.0)
      9|Resolved | 2|Apache Felix Security Provider (2.2.0)
      10|Active | 2|Apache Felix Shell Service (1.4.3)
      11|Installed | 2|Apache Log4j 1.x Compatibility API (2.0.0.beta8)
      12|Active | 2|Apache Log4j API (2.0.0.beta8)
      13|Installed | 2|Apache Log4j Commons Logging Bridge (2.0.0.beta8)
      14|Installed | 2|Apache Log4j Core (2.0.0.beta8)
      15|Installed | 2|Apache Log4j SLF4J Binding (2.0.0.beta8)
      16|Active | 2|cal10n-api (0.7.4)
      17|Active | 2|Commons IO (2.4.0)
      18|Active | 2|Commons Lang (2.6.0)
      19|Active | 2|Data mapper for Jackson JSON processor (1.9.13)
      20|Active | 2|Jackson JSON processor (1.9.13)
      21|Active | 2|JSON.simple (1.1.1)
      22|Installed | 2|slf4j-api (1.5.11)
      23|Installed | 2|slf4j-ext (1.5.11)

      Unresolved constraint in bundle org.apache.logging.log4j-slf4j-impl [15]: Unable to resolve 15.0: missing requirement [15.0] osgi.wiring.package; (osgi.wiring.package=org.slf4j) [caused by: Unable to resolve 22.0: missing requirement [22.0] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.impl)(version>=1.5.5))]

      Unresolved constraint in bundle slf4j.api [22]: Unable to resolve 22.0: missing requirement [22.0] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.impl)(version>=1.5.5))

      1. 0001-Add-SLF4J-related-bundles.patch
        12 kB
        Matt Sicker
      2. log4j2-slf4j-impl.patch
        2 kB
        Roland Weiglhofer

        Activity

        Hide
        Roland Weiglhofer added a comment -

        Please, we need a solution for our problem in the next few days. It blocks our development. Thank you very much

        Show
        Roland Weiglhofer added a comment - Please, we need a solution for our problem in the next few days. It blocks our development. Thank you very much
        Hide
        Remko Popma added a comment -

        Roland, we are all volunteers working on log4j in our spare time. Another factor is that we don't have much OSGi expertise in the team, so the quickest way to get this fixed is to provide a patch yourself.

        Show
        Remko Popma added a comment - Roland, we are all volunteers working on log4j in our spare time. Another factor is that we don't have much OSGi expertise in the team, so the quickest way to get this fixed is to provide a patch yourself.
        Hide
        Roland Weiglhofer added a comment -

        okay. I get it. Thanks for your reply! Regards

        Show
        Roland Weiglhofer added a comment - okay. I get it. Thanks for your reply! Regards
        Hide
        Roland Weiglhofer added a comment - - edited

        Hi,
        I changed the poms and I created a patch. It is a short term solution and there is a need for discussion. It is not fully tested but it works on my machine (Apache Felix Version 4.2.1). To whom should I send the patch-file?

        Regards
        Roland

        --------------------------------------------------------------------
        output

        lb
        START LEVEL 4
        ID|State |Level|Name
        0|Active | 0|System Bundle (4.2.1)
        4|Active | 2|Apache Felix Bundle Repository (1.6.6)
        5|Active | 2|Apache Felix Configuration Admin Service (1.6.0)
        6|Active | 2|Apache Felix Gogo Command (0.12.0)
        7|Active | 2|Apache Felix Gogo Runtime (0.10.0)
        8|Active | 2|Apache Felix Gogo Shell (0.10.0)
        9|Resolved | 2|Apache Felix Security Provider (2.2.0)
        10|Active | 2|Apache Felix Shell Service (1.4.3)
        11|Active | 2|Apache Log4j 1.x Compatibility API (2.0.0.beta9-SNAPSHOT)
        12|Active | 2|Apache Log4j API (2.0.0.beta9-SNAPSHOT)
        13|Active | 2|Apache Log4j Commons Logging Bridge (2.0.0.beta9-SNAPSHOT)
        14|Active | 2|Apache Log4j Core (2.0.0.beta9-SNAPSHOT)
        15|Active | 2|Apache Log4j SLF4J Binding (2.0.0.beta9-SNAPSHOT)
        16|Active | 2|cal10n-api (0.7.4)
        17|Active | 2|Commons Codec (1.6.0)
        18|Active | 2|Commons IO (2.4.0)
        19|Active | 2|Commons Lang (2.6.0)
        20|Active | 2|Data mapper for Jackson JSON processor (1.9.13)
        21|Active | 2|Disruptor Framework (3.1.1)
        22|Active | 2|Gson (2.2.4)
        23|Active | 2|Jackson JSON processor (1.9.13)
        24|Active | 2|Jackson-annotations (2.2.2)
        25|Active | 2|Jackson-core (2.2.2)
        26|Active | 2|jackson-databind (2.2.2)
        27|Active | 2|JSON.simple (1.1.1)
        28|Active | 2|MongoDB Java Driver (2.11.2.RELEASE)
        29|Active | 2|slf4j-api (1.7.5)
        30|Active | 2|slf4j-ext (1.7.5)

        Show
        Roland Weiglhofer added a comment - - edited Hi, I changed the poms and I created a patch. It is a short term solution and there is a need for discussion. It is not fully tested but it works on my machine (Apache Felix Version 4.2.1). To whom should I send the patch-file? Regards Roland -------------------------------------------------------------------- output lb START LEVEL 4 ID|State |Level|Name 0|Active | 0|System Bundle (4.2.1) 4|Active | 2|Apache Felix Bundle Repository (1.6.6) 5|Active | 2|Apache Felix Configuration Admin Service (1.6.0) 6|Active | 2|Apache Felix Gogo Command (0.12.0) 7|Active | 2|Apache Felix Gogo Runtime (0.10.0) 8|Active | 2|Apache Felix Gogo Shell (0.10.0) 9|Resolved | 2|Apache Felix Security Provider (2.2.0) 10|Active | 2|Apache Felix Shell Service (1.4.3) 11|Active | 2|Apache Log4j 1.x Compatibility API (2.0.0.beta9-SNAPSHOT) 12|Active | 2|Apache Log4j API (2.0.0.beta9-SNAPSHOT) 13|Active | 2|Apache Log4j Commons Logging Bridge (2.0.0.beta9-SNAPSHOT) 14|Active | 2|Apache Log4j Core (2.0.0.beta9-SNAPSHOT) 15|Active | 2|Apache Log4j SLF4J Binding (2.0.0.beta9-SNAPSHOT) 16|Active | 2|cal10n-api (0.7.4) 17|Active | 2|Commons Codec (1.6.0) 18|Active | 2|Commons IO (2.4.0) 19|Active | 2|Commons Lang (2.6.0) 20|Active | 2|Data mapper for Jackson JSON processor (1.9.13) 21|Active | 2|Disruptor Framework (3.1.1) 22|Active | 2|Gson (2.2.4) 23|Active | 2|Jackson JSON processor (1.9.13) 24|Active | 2|Jackson-annotations (2.2.2) 25|Active | 2|Jackson-core (2.2.2) 26|Active | 2|jackson-databind (2.2.2) 27|Active | 2|JSON.simple (1.1.1) 28|Active | 2|MongoDB Java Driver (2.11.2.RELEASE) 29|Active | 2|slf4j-api (1.7.5) 30|Active | 2|slf4j-ext (1.7.5)
        Hide
        Roland Weiglhofer added a comment -

        Index: slf4j-impl/pom.xml
        ===================================================================
        — slf4j-impl/pom.xml (revision 1516372)
        +++ slf4j-impl/pom.xml (working copy)
        @@ -24,7 +24,7 @@
        <relativePath>../</relativePath>
        </parent>
        <artifactId>log4j-slf4j-impl</artifactId>

        • <packaging>jar</packaging>
          + <packaging>bundle</packaging>
          <name>Apache Log4j SLF4J Binding</name>
          <description>SLF4J API binding to Log4j 2 Core</description>
          <properties>
          @@ -66,6 +66,22 @@
          <build>
          <plugins>
          <plugin>
          + <groupId>org.apache.felix</groupId>
          + <artifactId>maven-bundle-plugin</artifactId>
          + <extensions>true</extensions>
          + <inherited>true</inherited>
          + <configuration>
          + <instructions>
          + <Bundle-SymbolicName>$ {osgi.symbolicName}

          </Bundle-SymbolicName>
          + <Export-Package>$

          {osgi.export.slf4jbinding}

          </Export-Package>
          + <Private-Package>$

          {osgi.private}

          </Private-Package>
          + <Import-Package>$

          {osgi.import}

          </Import-Package>
          + <DynamicImport-Package>$

          {osgi.dynamicImport}

          </DynamicImport-Package>
          + <Bundle-DocURL>$

          {project.url}

          </Bundle-DocURL>
          + </instructions>
          + </configuration>
          + </plugin>
          + <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-surefire-plugin</artifactId>
          <configuration>
          Index: pom.xml
          ===================================================================

            • pom.xml (revision 1516096)
              +++ pom.xml (working copy)
              @@ -142,6 +142,8 @@
              <!-- Configuration properties for the OSGi maven-bundle-plugin -->
              <osgi.symbolicName>org.apache.logging.$ {project.artifactId}

              </osgi.symbolicName>
              <osgi.export>org.apache.logging.log4j.*;version=$

              {project.version};-noimport:=true</osgi.export>
              + <osgi.export.slf4jbinding>org.slf4j.impl;version=1.7.5,org.slf4j.helpers;version=1.7.5,org.apache.logging.slf4j;version=${project.version}

              </osgi.export.slf4jbinding>
              + <osgi.export.log4j1.2>org.apache.log4j;version=1.2,org.apache.log4j.helpers;version=1.2,org.apache.log4j.config;version=1.2,org.apache.log4j.spi;version=1.2,org.apache.log4j.xml;version=1.2</osgi.export.log4j1.2>
              <osgi.import>*</osgi.import>
              <osgi.dynamicImport />
              <osgi.private />

        Show
        Roland Weiglhofer added a comment - Index: slf4j-impl/pom.xml =================================================================== — slf4j-impl/pom.xml (revision 1516372) +++ slf4j-impl/pom.xml (working copy) @@ -24,7 +24,7 @@ <relativePath>../</relativePath> </parent> <artifactId>log4j-slf4j-impl</artifactId> <packaging>jar</packaging> + <packaging>bundle</packaging> <name>Apache Log4j SLF4J Binding</name> <description>SLF4J API binding to Log4j 2 Core</description> <properties> @@ -66,6 +66,22 @@ <build> <plugins> <plugin> + <groupId>org.apache.felix</groupId> + <artifactId>maven-bundle-plugin</artifactId> + <extensions>true</extensions> + <inherited>true</inherited> + <configuration> + <instructions> + <Bundle-SymbolicName>$ {osgi.symbolicName} </Bundle-SymbolicName> + <Export-Package>$ {osgi.export.slf4jbinding} </Export-Package> + <Private-Package>$ {osgi.private} </Private-Package> + <Import-Package>$ {osgi.import} </Import-Package> + <DynamicImport-Package>$ {osgi.dynamicImport} </DynamicImport-Package> + <Bundle-DocURL>$ {project.url} </Bundle-DocURL> + </instructions> + </configuration> + </plugin> + <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> Index: pom.xml =================================================================== pom.xml (revision 1516096) +++ pom.xml (working copy) @@ -142,6 +142,8 @@ <!-- Configuration properties for the OSGi maven-bundle-plugin --> <osgi.symbolicName>org.apache.logging.$ {project.artifactId} </osgi.symbolicName> <osgi.export>org.apache.logging.log4j.*;version=$ {project.version};-noimport:=true</osgi.export> + <osgi.export.slf4jbinding>org.slf4j.impl;version=1.7.5,org.slf4j.helpers;version=1.7.5,org.apache.logging.slf4j;version=${project.version} </osgi.export.slf4jbinding> + <osgi.export.log4j1.2>org.apache.log4j;version=1.2,org.apache.log4j.helpers;version=1.2,org.apache.log4j.config;version=1.2,org.apache.log4j.spi;version=1.2,org.apache.log4j.xml;version=1.2</osgi.export.log4j1.2> <osgi.import>*</osgi.import> <osgi.dynamicImport /> <osgi.private />
        Hide
        Roland Weiglhofer added a comment -

        I don't dare ask because I know that you are volunteers. But it would be nice to get some feedback if the patch is a acceptable solution, and when you have the time to apply it.

        Show
        Roland Weiglhofer added a comment - I don't dare ask because I know that you are volunteers. But it would be nice to get some feedback if the patch is a acceptable solution, and when you have the time to apply it.
        Hide
        Roland Weiglhofer added a comment -

        Sorry for the blocker, but we will soon decide whether log4j2 will be dead for the next few years or not.

        Show
        Roland Weiglhofer added a comment - Sorry for the blocker, but we will soon decide whether log4j2 will be dead for the next few years or not.
        Hide
        Matt Sicker added a comment -

        Here's a better patch. I've added two submodules to log4j-osgi that create bundles for log4j-to-slf4j and slf4j-impl.

        Show
        Matt Sicker added a comment - Here's a better patch. I've added two submodules to log4j-osgi that create bundles for log4j-to-slf4j and slf4j-impl.
        Hide
        Remko Popma added a comment - - edited

        Matt, I've committed your patch in revision 1569015, can you check?

        Before we mark this issue as resolved, what are your thoughts on naming things for OSGi?
        I noticed that in this patch, the two submodules have artifactIds log4j-to-slf4j-bundle and log4j-slf4j-impl-bundle, ending in "bundle". I actually kind of liked the convention we had before where the word "osgi" was in the artifactId.

        What about using this as the naming rule for OSGi sub-modules and artifactIds?

        submodule artifact Id
        log4j-osgi/moduleName<-optionalBundleName> log4j-osgi-moduleName<-optionalBundleName>

        So for the core bundles we have a bunch of sub-bundles, if there is only one osgi bundle per module we just use the module name. From the current osgi submodule names I would like to remove the word "osgi" (as they are all already submodules of the log4j-osgi module), and for the artifactIds I would like to prefix all of them with log4j-osgi. By giving them a common prefix, all resulting jar files are automatically grouped more clearly than when their names end in the bundle suffix.

        So I propose the following changes:

        current submodule proposed submodule current artifact Id proposed artifact Id
        log4j-osgi/core-osgi-legacy-api log4j-osgi/1.2-api log4j-1.2-osgi-api log4j-osgi-1.2-api
        log4j-osgi/core-osgi-async log4j-osgi/core-async log4j-core-osgi-async log4j-osgi-core-async
        log4j-osgi/core-osgi-jpa log4j-osgi/core-jpa log4j-core-osgi-jpa log4j-osgi-core-jpa
        log4j-osgi/core-osgi-net log4j-osgi/core-net log4j-core-osgi-net log4j-osgi-core-net
        log4j-osgi/core-osgi-nosql-couchdb log4j-osgi/core-nosql-couchdb log4j-core-osgi-nosql-couchdb log4j-osgi-core-nosql-couchdb
        log4j-osgi/core-osgi-nosql-mongodb log4j-osgi/core-nosql-mongodb log4j-core-osgi-nosql-mongodb log4j-osgi-core-nosql-mongodb
        log4j-osgi/core-osgi-reduced log4j-osgi/core-reduced log4j-core-osgi-reduced log4j-osgi-core-reduced
        log4j-osgi/log4j-to-slf4j log4j-osgi/log4j-to-slf4j log4j-to-slf4j-bundle log4j-osgi-to-slf4j
        log4j-osgi/slf4j-to-log4j log4j-osgi/slf4j-impl log4j-slf4j-impl-bundle log4j-osgi-slf4j-impl

        Thoughts?

        Show
        Remko Popma added a comment - - edited Matt, I've committed your patch in revision 1569015, can you check? Before we mark this issue as resolved, what are your thoughts on naming things for OSGi? I noticed that in this patch, the two submodules have artifactIds log4j-to-slf4j-bundle and log4j-slf4j-impl-bundle , ending in "bundle". I actually kind of liked the convention we had before where the word "osgi" was in the artifactId. What about using this as the naming rule for OSGi sub-modules and artifactIds? submodule artifact Id log4j-osgi/moduleName<-optionalBundleName> log4j-osgi-moduleName<-optionalBundleName> So for the core bundles we have a bunch of sub-bundles, if there is only one osgi bundle per module we just use the module name. From the current osgi submodule names I would like to remove the word "osgi" (as they are all already submodules of the log4j-osgi module), and for the artifactIds I would like to prefix all of them with log4j-osgi . By giving them a common prefix, all resulting jar files are automatically grouped more clearly than when their names end in the bundle suffix. So I propose the following changes: current submodule proposed submodule current artifact Id proposed artifact Id log4j-osgi/core- osgi -legacy-api log4j-osgi/1.2-api log4j- 1.2-osgi -api log4j-osgi-1.2-api log4j-osgi/core- osgi -async log4j-osgi/core-async log4j- core-osgi -async log4j-osgi-core-async log4j-osgi/core- osgi -jpa log4j-osgi/core-jpa log4j- core-osgi -jpa log4j-osgi-core-jpa log4j-osgi/core- osgi -net log4j-osgi/core-net log4j- core-osgi -net log4j-osgi-core-net log4j-osgi/core- osgi -nosql-couchdb log4j-osgi/core-nosql-couchdb log4j- core-osgi -nosql-couchdb log4j-osgi-core-nosql-couchdb log4j-osgi/core- osgi -nosql-mongodb log4j-osgi/core-nosql-mongodb log4j- core-osgi -nosql-mongodb log4j-osgi-core-nosql-mongodb log4j-osgi/core- osgi -reduced log4j-osgi/core-reduced log4j- core-osgi -reduced log4j-osgi-core-reduced log4j-osgi/log4j-to-slf4j log4j-osgi/log4j-to-slf4j log4j-to-slf4j -bundle log4j-osgi-to-slf4j log4j-osgi/slf4j- to-log4j log4j-osgi/slf4j-impl log4j-slf4j-impl -bundle log4j-osgi-slf4j-impl Thoughts?
        Hide
        Matt Sicker added a comment -

        Shouldn't the module names match the artefact names in some way? Like for instance, log4j-core-osgi-jpa should be in a directory called log4j-core-osgi-jpa. I'm not positive on that, but it seems to be common Maven practice to do so. At least that's what I could grok from the maven site plugin bug MSITE-695 mentioned in the root pom.

        Also, I'd prefer to use the name "bundle" over "osgi". I would think that including "osgi" in the name indicates specific OSGi framework things like implementations of core or compendium OSGi services, etc. Then you'd get a name like log4j-bundle-core-jpa which kind of looks weird. I'd prefer log4j-core-jpa-bundle. This way, all the normal JARs have corresponding *-bundle JARs as well.

        Show
        Matt Sicker added a comment - Shouldn't the module names match the artefact names in some way? Like for instance, log4j-core-osgi-jpa should be in a directory called log4j-core-osgi-jpa. I'm not positive on that, but it seems to be common Maven practice to do so. At least that's what I could grok from the maven site plugin bug MSITE-695 mentioned in the root pom. Also, I'd prefer to use the name "bundle" over "osgi". I would think that including "osgi" in the name indicates specific OSGi framework things like implementations of core or compendium OSGi services, etc. Then you'd get a name like log4j-bundle-core-jpa which kind of looks weird. I'd prefer log4j-core-jpa-bundle. This way, all the normal JARs have corresponding *-bundle JARs as well.
        Hide
        Remko Popma added a comment -

        It's probably best to aim to match OSGi users expectations. So if it is common practice to have a some-functionality.jar and a some-functionality-bundle.jar then I'm fine with that.

        About the module names matching the artifact names, I think you're right about this being a recommended practice, but adding "log4j-" to the beginning and "-bundle" to the end of every folder name just makes the names 11 chars longer without actually adding meaning. Not a fan... But if everyone prefers it that way then I can live with it.

        Show
        Remko Popma added a comment - It's probably best to aim to match OSGi users expectations. So if it is common practice to have a some-functionality.jar and a some-functionality-bundle.jar then I'm fine with that. About the module names matching the artifact names, I think you're right about this being a recommended practice, but adding "log4j-" to the beginning and "-bundle" to the end of every folder name just makes the names 11 chars longer without actually adding meaning. Not a fan... But if everyone prefers it that way then I can live with it.
        Hide
        Matt Sicker added a comment -

        I prefer the shorter directory names like you suggested since the context is clear with parent directories. However, it really does depend on how Maven works with sub-modules.

        Show
        Matt Sicker added a comment - I prefer the shorter directory names like you suggested since the context is clear with parent directories. However, it really does depend on how Maven works with sub-modules.
        Hide
        Stefan Klaus added a comment -

        Is the Patch already committed to the trunk. I build the trunk version locally, but was not able to start my app with slf4j 1.7.6 and the trunk bundles (api, core and log4j-slf4j-impl-bundle).
        Is there any documentation on how to use log4j-osgi-slf4j-impl?

        Show
        Stefan Klaus added a comment - Is the Patch already committed to the trunk. I build the trunk version locally, but was not able to start my app with slf4j 1.7.6 and the trunk bundles (api, core and log4j-slf4j-impl-bundle). Is there any documentation on how to use log4j-osgi-slf4j-impl?
        Hide
        Matt Sicker added a comment -

        This was fixed quite recently with the bundle config cleanups.

        Show
        Matt Sicker added a comment - This was fixed quite recently with the bundle config cleanups.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development