@Ali Loyuncu- excellent; glad to hear.  Cheers.

On Tue, Jun 7, 2016 at 6:27 AM, Ali Koyuncu <[email protected]> wrote:

> Sorry for my late response.
>
> Thank you, John. What you advised below solved my problem.
>
> Cheers,
>
> Ali
>
>
> On Mon, Jun 6, 2016 at 9:46 PM, John Blum <[email protected]> wrote:
>
>> 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)
>>
>
>
>
> --
>
> Saygılarımla, with my warm regards,
>
> Ali KOYUNCU
>



-- 
-John
503-504-8657
john.blum10101 (skype)

Reply via email to