glassfish
  1. glassfish
  2. GLASSFISH-11129

Weld encounters SLF4J error: Class path contains multiple SLF4J bindings.

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: V3
    • Fix Version/s: V3
    • Component/s: OSGi
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      11,129

      Description

      During Weld TCK run, the following error appears in the log:
      [#|2009-11-22T00:45:19.657+0530|SEVERE|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=24;_ThreadName=AutoDeployer;|SLF4J:
      Class path contains multiple SLF4J bindings.|#]

      [#|2009-11-22T00:45:19.657+0530|SEVERE|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=24;_ThreadName=AutoDeployer;|SLF4J:
      Found binding in
      [jar:file:/space/ss141213/WS/gf/v3/publish/glassfishv3/glassfish/modules/bean-validator.jar!/org/slf4j/impl/StaticLoggerBinder.class]|#]

      [#|2009-11-22T00:45:19.657+0530|SEVERE|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=24;_ThreadName=AutoDeployer;|SLF4J:
      Found binding in [bundle://56.0:1/org/slf4j/impl/StaticLoggerBinder.class]|#]

      [#|2009-11-22T00:45:19.660+0530|SEVERE|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=24;_ThreadName=AutoDeployer;|SLF4J:
      See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.|#]

        Activity

        Hide
        jthoennes added a comment -

        Thanks for coming back to me:

        Here is the list of GF jars in our CLASSPATH:

        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/lib/appserv-rt.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/lib/javaee.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/lib/install/applications/jmsra/imqjmsra.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/auto-depends.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/amx-config.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/amx-core.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/amx-ext-impl.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/amx-j2ee-impl.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/console-common.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/glassfish-api.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/javax.ejb.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/javax.jms.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/javax.persistence.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/javax.resource.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/javax.servlet.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/endorsed/javax.annotation.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/mail.jar
        /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/management-api.jar

        We need them for different stuff, e.g. AMX etc. If you suggest alternative ways,
        please point this out. Is this documented somewhere in the GF docs?

        Thanks, Jörg

        Show
        jthoennes added a comment - Thanks for coming back to me: Here is the list of GF jars in our CLASSPATH: /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/lib/appserv-rt.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/lib/javaee.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/lib/install/applications/jmsra/imqjmsra.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/auto-depends.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/amx-config.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/amx-core.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/amx-ext-impl.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/amx-j2ee-impl.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/console-common.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/glassfish-api.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/javax.ejb.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/javax.jms.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/javax.persistence.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/javax.resource.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/javax.servlet.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/endorsed/javax.annotation.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/mail.jar /opt2/Glassfish/linux/glassfish-v3.0.1/glassfish/modules/management-api.jar We need them for different stuff, e.g. AMX etc. If you suggest alternative ways, please point this out. Is this documented somewhere in the GF docs? Thanks, Jörg
        Hide
        jthoennes added a comment -

        Sahoo, I just file Oracle Service Request on behalf on our service contract:

        • SR 3-3807162601: SLF4J: Class path contains multiple SLF4J bindings

        and pointed to this ticket for more information.

        Please, would you mind to help me with this issue?

        Thanks, Jörg

        Show
        jthoennes added a comment - Sahoo, I just file Oracle Service Request on behalf on our service contract: SR 3-3807162601: SLF4J: Class path contains multiple SLF4J bindings and pointed to this ticket for more information. Please, would you mind to help me with this issue? Thanks, Jörg
        Hide
        Sanjeeb Sahoo added a comment -

        Jörg,

        Is the slf4j message not just a warning? Their documentation [1] says so:
        "Note that the warning emitted by SLF4J is just that, a warning. SLF4J will still bind with the first framework it finds on the class path."

        So, why exactly are you worried? If you want to use a different slf4j binding, you can still do it by having it in classpath ahead of glassfish jars in non-osgi environment.

        Sahoo

        [1] http://www.slf4j.org/codes.html#multiple_bindings

        Show
        Sanjeeb Sahoo added a comment - Jörg, Is the slf4j message not just a warning? Their documentation [1] says so: "Note that the warning emitted by SLF4J is just that, a warning. SLF4J will still bind with the first framework it finds on the class path." So, why exactly are you worried? If you want to use a different slf4j binding, you can still do it by having it in classpath ahead of glassfish jars in non-osgi environment. Sahoo [1] http://www.slf4j.org/codes.html#multiple_bindings
        Hide
        jthoennes added a comment -

        Sahoo,

        sure it is just warning, but it the stdout of our command-line processes:
        extra 4 lines multiple times. Therefore, this is for us really annoying.

        Cheers, Jörg

        Show
        jthoennes added a comment - Sahoo, sure it is just warning, but it the stdout of our command-line processes: extra 4 lines multiple times. Therefore, this is for us really annoying. Cheers, Jörg
        Hide
        Sanjeeb Sahoo added a comment -

        Should slf4j not be configurable to disable that warning? You should definitely ask them to make it configurable.

        I suppose we can't wait for them to make the change. In the mean while, can you avoid having appserv-rt.jar and javaee.jar in classpath? In place of them, add individual jars from modules/ dir. I see you are primarily doing AMX programming, so you should not be requiring weld-osgi.jar in classpath.

        These are exactly the problems a classpath based system faces which OSGi so elegantly solves.

        Show
        Sanjeeb Sahoo added a comment - Should slf4j not be configurable to disable that warning? You should definitely ask them to make it configurable. I suppose we can't wait for them to make the change. In the mean while, can you avoid having appserv-rt.jar and javaee.jar in classpath? In place of them, add individual jars from modules/ dir. I see you are primarily doing AMX programming, so you should not be requiring weld-osgi.jar in classpath. These are exactly the problems a classpath based system faces which OSGi so elegantly solves.

          People

          • Assignee:
            Sanjeeb Sahoo
            Reporter:
            Sanjeeb Sahoo
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: