PLEAS READ CAREFULLY...
Yes, both are binding JARs, and as warning message states, both are present
on your application's CLASSPATH currently.
But... technically, the binding JAR you *need* depends on which logging
framework your application uses and what logging provider (e.g. log4j,
logback, whichever) performs the actual logging (i.e. to console, to file,
whatever).
*Examples...*
~~~~
If you are using the slf4j "API" in your application and log4j as the
"provider", then you will need the slf4j-log4j12 binding and will need to
exclude the log4j-slf4j-impl from your application's CLASSPATH.
However, if you are using slf4j and another logging provider (e.g.
logback), then you need to exclude both log4-slf4j-impl AND slf4j-log4j12
bindings (since logback is a binding and implements the slf4j API when
present on the CLASSPATH).
~~~~
NOTE: Geode should not be pulling in any binding JARS; if it is, that is a
bug! In addition, Geode should not be dictating the logging framework nor
the provider your application uses.
In addition, it is highly likely 1 or more of your application dependencies
are *pulling in different bindings* as well as different versions of the
same API (e.g. SLF4J), hence 1 reason you added an slf4j-log4j12 exclusion
on the org.simpleframework:simple-xml:2.6 API.
All problems can be corrected by a combination of proper dependency
declarations [with exclusions (as necessary)] and a dependency management
section in your application POM file.
NOTE: the dependencyManagement section is only for constraining dependency
versions when your application transitive dependencies potentially pull in
competing versions.
By way of example, and in closing, let's assume you are using the *slf4j*
API in your application and *logback* as the *provider*. As Jens points
out, we also know Geode uses *log4j*. So, you application POM file would
look similar too..
<repositories>
...
</repositories>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.slfj4</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.7</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>*logback-classic*</artifactId>
<version>1.0.13</version>
</dependency>
<dependency>
<groupId>org.apache.geode</groupId>
<artifactId>geode-core</artifactId>
<version>1.0.0-incubating.M2</version>
<exclusions>
* <exclusion>*
* <groupId>org.slf4j</groupId>*
* <artifactId>log4j-slf4j-impl</artifactId>*
* </exclusion>*
</exclusions>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slfj4</artifactId>
<version>1.7.7</version>
</dependency>
...
</dependencies>
The logback-classic dependency will pull in slf4j-api.
The log4j-over-slf4j is a "bridge" JAR
<http://www.slf4j.org/legacy.html#log4j-over-slf4j> [1] (not a binding)
that routes all log4j statements in Geode to your slf4j provider (i.e.
logback) so that Geode logs information based on your logback configuration.
I added an exclusion for the log4j-slf4j-impl binding in the geode-core
dependency, since unfortunately (upon inspecting the Geode POM file
<https://repo1.maven.org/maven2/org/apache/geode/geode-core/1.0.0-incubating.M2/geode-core-1.0.0-incubating.M2.pom>
[2])
Geode pulls in the binding
<http://logging.apache.org/log4j/2.x/log4j-to-slf4j/index.html> [3]; a
definite BUG!
You should refer to the SLF4J user manual on bindings
<http://www.slf4j.org/manual.html#swapping> [4]. Also, Bridging legacy APIs
<http://www.slf4j.org/legacy.html> [5] is a good reference when your
application dependencies and the transitive dependencies are using a
menagerie of logging frameworks (e.g. JUL, JCL, log4j, logback, etc, etc).
The diagram shows you examples of what you would need on your application
CLASSPATH.
Finally, when in doubt, you can use Mavens dependency plugin to inspect
your dependency graph. From the command-line in your application/project
root directory, run...
$ mvn dependency:tree
Likewise, with Gradle...
$ gradlew dependencies
For example, from a Apache Geode checkout...
$ gradlew geode-core:dependencies | less
Hope this helps!
Cheers,
John
[1] http://www.slf4j.org/legacy.html#log4j-over-slf4j
[2]
https://repo1.maven.org/maven2/org/apache/geode/geode-core/1.0.0-incubating.M2/geode-core-1.0.0-incubating.M2.pom
[3] http://logging.apache.org/log4j/2.x/log4j-to-slf4j/index.html
[4] http://www.slf4j.org/manual.html#swapping
[5] http://www.slf4j.org/legacy.html
On Mon, Jun 6, 2016 at 7:55 AM, Jens Deppe <[email protected]> wrote:
> Hi Ali,
>
> As the messages state, both log4j-slf4j-impl-2.5 (for log4j >= 2.0) and
> slf4j-log4j12 (for log4j < 2.0) are binding jars, meaning that they are
> binding slf4j to a concrete logging framework in order to actually produce
> log messages. As Geode uses log4j 2.x you do not need slf4j-log4j12 and it
> should be excluded from your dependencies.
>
> --Jens
>
> On Mon, Jun 6, 2016 at 2:49 AM, Ali Koyuncu <[email protected]> wrote:
>
>> Hi, John,
>>
>> I have arranged as follows:
>>
>> <dependencies>
>>
>> <dependency>
>> <groupId>org.simpleframework</groupId>
>> <artifactId>simple-xml</artifactId>
>> <version>2.6</version>
>> </dependency>
>>
>> <dependency>
>> <groupId>org.apache.geode</groupId>
>> <artifactId>gemfire-core</artifactId>
>> <version>1.0.0-incubating.M1</version>
>> </dependency>
>>
>>
>> <!-- http://mvnrepository.com/artifact/org.asteriskjava/asterisk-java -->
>> <dependency>
>> <groupId>org.asteriskjava</groupId>
>> <artifactId>asterisk-java</artifactId>
>> <version>1.0.0.M3</version>
>> <exclusions>
>> <exclusion>
>> <groupId>com.sun.jmx</groupId>
>> <artifactId>jmxri</artifactId>
>> </exclusion>
>> <exclusion>
>> <groupId>com.sun.jdmk</groupId>
>> <artifactId>jmxtools</artifactId>
>> </exclusion>
>> <exclusion>
>> <groupId>javax.jms</groupId>
>> <artifactId>jms</artifactId>
>> </exclusion>
>> </exclusions>
>> </dependency>
>>
>>
>> <dependency>
>> <groupId>eu.exodussoft.css.commons</groupId>
>> <artifactId>csscommons</artifactId>
>> <version>0.1.0</version>
>> </dependency>
>>
>> </dependencies>
>>
>> <dependencyManagement>
>> <dependencies>
>>
>> <!-- http://mvnrepository.com/artifact/ch.qos.logback/logback-core -->
>> <dependency>
>> <groupId>ch.qos.logback</groupId>
>> <artifactId>logback-core</artifactId>
>> <version>1.1.3</version>
>> </dependency>
>> <dependency>
>> <groupId>org.slf4j</groupId>
>> <artifactId>slf4j-log4j12</artifactId>
>> <version>1.7.7</version>
>> </dependency>
>> <dependency>
>> <groupId>org.slf4j</groupId>
>> <artifactId>slf4j-log4j12</artifactId>
>> <version>1.7.7</version>
>> </dependency>
>> </dependencies>
>> </dependencyManagement>
>>
>>
>> However, it doesn't work... No logs... and it gives the following message
>> (should I ignore these warnings?):
>>
>> SLF4J: Class path contains multiple SLF4J bindings.
>> SLF4J: Found binding in
>> [jar:file:/C:/Users/admin/.m2/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.5/log4j-slf4j-impl-2.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
>> SLF4J: Found binding in
>> [jar:file:/C:/Users/admin/.m2/repository/org/slf4j/slf4j-log4j12/1.7.7/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
>> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an
>> explanation.
>> SLF4J: Actual binding is of type
>> [org.apache.logging.slf4j.Log4jLoggerFactory]
>>
>>
>> On Sun, Jun 5, 2016 at 1:19 AM, John Blum <[email protected]> wrote:
>>
>>> Rather than "excluding" the dependency, you rather might add a
>>> dependency management section to your application POM file to ensure that
>>> only a single version of the SLF4J dependencies (and in particular, the
>>> slf4j-log4j12 bridge) is present. For example...
>>>
>>> <dependencyManagement>
>>> <dependencies>
>>> <dependency>
>>> <groupId>org.slf4j</groupId>
>>> <artifactId>slf4j-log4j12</artifactId>
>>> *<version>1.7.7</version>*
>>> </dependency>
>>> </dependencies>
>>> </dependencyManagement>
>>>
>>> The version is based on the version called out in the
>>> dependency-versions.properties
>>> <https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M2/gradle/dependency-versions.properties#L86>
>>> [1]
>>> file.
>>>
>>> To my understanding, *Apache Geode* at version *1.0.0-incubating.M2*
>>> had properly resolved all dependencies and cleaned up the dependency
>>> graph/tree so that only a single version of any dependency is present. Are
>>> you using SLF4J in your application and possibly pulling in a different
>>> version?
>>>
>>> Either way, no matter, the "dependencyManagement" section will properly
>>> constrain the SLF4J dependencies. You can declare any other possibly
>>> conflicting dependencies in the dependencyManagement section of your POM
>>> file as well.
>>>
>>> Hope this helps!
>>>
>>> -John
>>>
>>>
>>> [1]
>>> https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M2/gradle/dependency-versions.properties#L86
>>>
>>>
>>> On Sat, Jun 4, 2016 at 8:49 AM, Ali Koyuncu <[email protected]>
>>> wrote:
>>>
>>>> Hi, everyone,
>>>>
>>>> Everything with my Java code seems all right. However, when I am to
>>>> deploy SLF4J and Log4J, I have the following run-time exception/warning:
>>>>
>>>> "Multiple SLF4J bindings on the classpath"
>>>>
>>>> Well, to get rid of this warning/exception, in *pom.xml *I have
>>>> arranged the dependencies as follows:
>>>>
>>>> <dependencies>
>>>>
>>>>
>>>> <dependency>
>>>>
>>>> <groupId>org.simpleframework</groupId>
>>>>
>>>> <artifactId>simple-xml</artifactId>
>>>>
>>>> <version>2.6</version>
>>>>
>>>> <exclusions>
>>>>
>>>> <exclusion>
>>>>
>>>> <groupId>org.slf4j</groupId>
>>>>
>>>> <artifactId>slf4j-log4j12</artifactId>
>>>>
>>>> </exclusion>
>>>>
>>>> </exclusions>
>>>>
>>>> </dependency>
>>>>
>>>>
>>>> <dependency>
>>>>
>>>> <groupId>org.apache.geode</groupId>
>>>>
>>>> <artifactId>gemfire-core</artifactId>
>>>>
>>>> <version>1.0.0-incubating.M1</version>
>>>>
>>>> <exclusions>
>>>>
>>>> <exclusion>
>>>>
>>>> <groupId>org.slf4j</groupId>
>>>>
>>>> <artifactId>slf4j-log4j12</artifactId>
>>>>
>>>> </exclusion>
>>>>
>>>> </exclusions>
>>>>
>>>> </dependency>
>>>>
>>>>
>>>> </dependencies>
>>>>
>>>>
>>>> After that, the warning message disappears. On Eclipse, everything
>>>> seems fine. However, when I am to deploy this code in Ubuntu, no log file
>>>> is generated -- I also tried different combinations.
>>>>
>>>> Any comments on how to solve this case will be appreciated.
>>>>
>>>> Thank you in advance.
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> With my warm regards,
>>>>
>>>> Ali KOYUNCU
>>>>
>>>
>>>
>>>
>>> --
>>> -John
>>> 503-504-8657
>>> john.blum10101 (skype)
>>>
>>
>>
>>
>> --
>>
>> Saygılarımla, with my warm regards,
>>
>> Ali KOYUNCU
>>
>
>
--
-John
503-504-8657
john.blum10101 (skype)
