In cases when you have two SLF4J bindings on the classpath, it essentially chooses the first to show up on the classpath. That'll usually be the case given the Storm libdir is read first.
"With our current setup if someone doesn't exclude things properly it crashes." How so? Because of slf4j-log4j12 and log4j-over-slf4j? You'll still need log4j-over-slf4j or log4j2's log4j-1.2-api to account for log4j 1.2.x users, the package changed. *Michael Rose* Senior Platform Engineer *Full*Contact | fullcontact.com <https://www.fullcontact.com/?utm_source=FullContact%20-%20Email%20Signatures&utm_medium=email&utm_content=Signature%20Link&utm_campaign=FullContact%20-%20Email%20Signatures> m: +1.720.837.1357 | t: @xorlev All Your Contacts, Updated and In One Place. Try FullContact for Free <https://www.fullcontact.com/?utm_source=FullContact%20-%20Email%20Signatures&utm_medium=email&utm_content=Signature%20Link&utm_campaign=FullContact%20-%20Email%20Signatures> On Mon, Feb 9, 2015 at 10:43 AM, Bobby Evans <[email protected]> wrote: > I'm not totally positive on this, but the little test I ran did not cause > any serious issues. I created a small project that just logs using slf4j > and log4j 1.2 API with the slf4j log4j2 bridge and the log4j1.2 > compatibility bridge on the classpath. > > ```package test; > > import org.slf4j.Logger; > import org.slf4j.LoggerFactory; > > public class Test { > private static final Logger LOG = LoggerFactory.getLogger(Test.class); > private static final org.apache.log4j.Logger logger = > org.apache.log4j.Logger.getLogger(Test.class); > public static void main(String[] args) { > System.out.println("Testing..."); > LOG.error("slf4j Testing..."); > logger.error("log4j Testing..."); > } > }``` > I then manipulated the classpath to have log4j-1.2 and slf4j-log4j12 at > the end of the classpath so that the log4j2 jars would override any log4j1 > jars. > > mvn exec:exec -Dexec.executable=java -Dexec.args="-cp > %classpath:~/.m2/repository/org/slf4j/slf4j-log4j12/1.7.10/slf4j-log4j12-1.7.10.jar:~/.m2/repository/log4j/log4j/1.2.17/log4j-1.2.17.jar > test.Test" > > I got out the log messages I expected, and an error messages about > multiple bindings that I think we can ignore. > SLF4J: Class path contains multiple SLF4J bindings. > SLF4J: Found binding in > [jar:file:/Users/evans/.m2/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.1/log4j-slf4j-impl-2.1.jar!/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: Found binding in > [jar:file:/Users/evans/.m2/repository/org/slf4j/slf4j-log4j12/1.7.10/slf4j-log4j12-1.7.10.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] > ERROR StatusLogger No log4j2 configuration file found. Using default > configuration: logging only errors to the console. > Testing... > 11:36:53.880 [main] ERROR test.Test - slf4j Testing... > 11:36:53.881 [main] ERROR test.Test - log4j Testing... > To me I can live with SLF4J spitting out error messages, at least all of > the logs come out. With our current setup if someone doesn't exclude > things properly it crashes. > > - Bobby > > > On Monday, February 9, 2015 10:59 AM, Michael Rose < > [email protected]> wrote: > > > slf4j-log4j12 would still need to be excluded with log4j2, as you must use > slf4j-log4j2. log4j2 its self has a package and coordinate change, so now > people would be excluding sfl4j-log4j12, log4j 1.2 and logback. Switching > to log4j2 does not solve that particular issue and perhaps slightly > exacerbates it. > > If the only reason is to have a RFC5424-compliant syslog appender, why not > fix logback's or build a separate one? > > *Michael Rose* > Senior Platform Engineer > *Full*Contact | fullcontact.com > < > https://www.fullcontact.com/?utm_source=FullContact%20-%20Email%20Signatures&utm_medium=email&utm_content=Signature%20Link&utm_campaign=FullContact%20-%20Email%20Signatures > > > m: +1.720.837.1357 | t: @xorlev > > > All Your Contacts, Updated and In One Place. > Try FullContact for Free > < > https://www.fullcontact.com/?utm_source=FullContact%20-%20Email%20Signatures&utm_medium=email&utm_content=Signature%20Link&utm_campaign=FullContact%20-%20Email%20Signatures > > > > On Mon, Feb 9, 2015 at 9:35 AM, Harsha <[email protected]> wrote: > > > I am +1 on switching to log4j. I second Bobby on excluding log4j and new > > users/devs run into this issue quite often. > > Thanks, > > Harsha > > > > On Mon, Feb 9, 2015, at 08:28 AM, Bobby Evans wrote: > > > I haven't seen any reply to this yet. It is a real pain to repeatedly > > > tell our downstream users to run mvn dependecy:tree look for slf4j > log4j > > > bindings and exclude them. That alone is enough for me to say lets > > > switch. > > > - Bobby > > > > > > > > > On Monday, February 2, 2015 3:07 PM, Derek Dagit > > > <[email protected]> wrote: > > > > > > > > > In the past, the storm project used log4j version 1.x as its logging > > > framework. Around the time of 0.9.0, before moving to Apache, the > > > project > > > moved to using logback for two reasons: > > > > > > 1) logback supported rolling log files, which was critical for managing > > > disk > > > space usage. > > > 2) logback supported dynamically updating its logging configuration > > > files. > > > > > > > > > Recently, we have met a new requirement that we send logs to a syslog > > > daemon > > > for further processing. The syslog daemon has a particular format > > > described in > > > RFC5424, and using it basically means that things like stack traces > have > > > newlines properly contained within a single logging event, instead of > > > written > > > raw into the log making extra parsing necessary. > > > > > > log4j version 2.x (or log4j2) has the following: > > > > > > 1) rolling log files with size, duration, and date-based triggers that > > > can be > > > composed together > > > 2) dynamic log updates that do not cause log messages to be dropped > while > > > the > > > new config is loaded > > > 3) a Syslog appender that is compliant with RFC5424. > > > > > > > > > I would like to hear developers' opinions on whether it might be good > to > > > switch > > > from logback to log4j2 based on the above, or else hear about > alternative > > > solutions to the RFC5424 requirement that works well. > > > > > > > > > Thanks, > > > -- > > > Derek > > > > > > > > > > > > > > >
