Russell E Glaue wrote:
Okay then, this is great.
Then despite the fact that both Geronimo and Jetty do not implement the latest slf4j, they can implement the latest logback-core/access.
I have already requested that Jetty implement the latest 1.5.6 of slf4j, it is in issue: http://jira.codehaus.org/browse/JETTY-865
I will do the same for Geronimo.
Thank you.
But since logback-core/access is not tied in dependency to slf4j, I can request the upgrade for slf4j and support for logback both at the same time.
Yes.
And when slf4j web site (http://www.slf4j.org/) lists, on the left side, that logback is a native implementation, it is referring to logback-classic only as the native implementation of slf4j. So I would assume logback-classic does have a dependency on slf4j since it is performing native implementation of it.
That is correct.
Since we are on this topic, can you answer the same question in regards to logback-classic: Can any application use slf4j 1.3.1 OR slf4j 1.4.3 libraries, and then at the same time use logback-classic 0.9.14 libraries without any problems? Or will there be a dependency conflict? In other words, is logback-classic dependent on slf4j?
Logback-classic depends on slf4j-api, since it is an implementation of that API. In SLF4J-speak, logback-classic is a binding for the SLF4J API, the same way as slf4j-simple or slf4j-log412. See the "slf4j-api version does not match that of the binding" entry in SLF4J's error code explanation page: http://slf4j.org/codes.html#version_mismatch You might also want to read: http://slf4j.org/faq.html#version_checks HTH,
-RG -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch