Announcement Announcement Module
No announcement yet.
SLF4J problem Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • SLF4J problem


    We experienced some problem with SLF4J when trying to deploy our bundles to Spring DM Server.

    Basically our bundles depend on a different version of SLF4J (1.5.8 patched with customized code), while Spring DM Server uses 1.5.6. What we did was to deploy both our bundles and the customized SLF4J bundle into repository/bundles/usr directory, and remove two files from repository/bundles/ext directory --- and (our bundles could’t be deployed if these two were not removed). Then, when were tried our test bundles, we got the following error in the trace file:

    [2009-08-25 13:19:08.763] server-dm-4 System.err E SLF4J: Class path contains multiple SLF4J bindings.
    [2009-08-25 13:19:08.763] server-dm-4 System.err E SLF4J: Found binding in [jar:file:/C:/springsource/dm-server-1.0.2/lib/com.springsource.server.serviceability.tracing-1.0.2.RELEASE.jar!/org/slf4j/impl/StaticLoggerBinder.class]
    [2009-08-25 13:19:08.763] server-dm-4 System.err E SLF4J: Found binding in [jar:file:C:\springsource\dm-server-1.0.2\work\equinox-config\org.eclipse.osgi\bundles\76\1\bundlefile!/org/slf4j/impl/StaticLoggerBinder.class]
    [2009-08-25 13:19:08.763] server-dm-4 System.err E SLF4J: See for an explanation.

    From the error, looks like Spring DM Server loaded a version of SLF4J from C:/springsource/dm-server-1.0.2/lib/com.springsource.server.serviceability.tracing-1.0.2.RELEASE.jar, which is conflicting with our own version. In the lib directory there are two files: and that cannot be removed without causing errors.

    If there any way to swap in our own version of SLF4J? We tried to put our own version of SLF4J in the lib directory but it caused errors when the DM Server started.



  • #2
    I think the better way to use is as follows

    1. Do not delete any bundles from m server lib or ext

    2. Instead put ur custom slf4j jars into bundles/usr. In your application bundles use teh import as follows



    • #3
      One disadvantage of coding bundle symbolic names is that this is fragile if bundles are refactored. Alternatively, you could specify a matching attribute, such as "type=custom", on your custom SLF4J package exports and package imports.

      However, please note that this whole approach will work only so long as the different instances of the SLF4J types in the system never need to interact.


      • #4
        Hi Andy,

        Can u just elaborate on the exact syntax for usage of this "type=custom".

        How will my exports and imports look assuming org.slf4j is the package ?

        Export-Package : org.slf4j; type=custom ???

        Import-Package :org.slf4j ???


        • #5
          Please refer to the OSGi core specification for definitive answers to syntax questions.

          Matching attributes are coded like this:
          export-package: p;type=custom
          import-package: p;type=custom
          You can even force anyone who wires to the export to specify the matching attribute by making it mandatory, thus:
          export-package: p;type=custom;mandatory:="type"
          This would prevent any bundle coding
          import-package: p
          from wiring to the "custom" export.

          You can have as many matching attributes as you like and can call them (almost - see the spec) anything you like.

          Glyn (not Andy)


          • #6
            Thanks Glyn :-)


            • #7
              Thanks Glyn and sudheerk84!

              We will have a try.