SLF4J problem

[wsun]

Hi,

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 --- com.springsource.slf4j.org.apache.log4j-1.5.6.jar and com.springsource.slf4j.org.apache.log4j-sources-1.5.6.jar (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 http://www.slf4j.org/codes.html#multiple_bindings 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: com.springsource.slf4j.org.apache.log4j-1.5.6.jar and com.springsource.slf4j.org.apache.commons.logging-1.5.6.jar 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.

Thanks,

Wei

[sudheerk84]

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


Import-Package: org.slf4j.xxx.yyy;bundle-symbolic-name="<UR_CUSTOM_BUNDLE_SYMBOLIC_NAME>"

[Glyn Normington]

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.

[sudheerk84]

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 ???

[Glyn Normington]

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)

[sudheerk84]

Thanks Glyn :-)

[wsun]

Thanks Glyn and sudheerk84!

We will have a try.