I'm okay with switching logging frameworks (I hate most of them equally ;) ), but I would like to stick with slf4j as the logging api so changes like this are easy.
However, we may want to at least consider polling users@, and make sure the change is well documented. The impact to devs is small, but could have a much larger impact on users. -Taylor > On Feb 9, 2015, at 1:25 PM, Bobby Evans <[email protected]> wrote: > > Yes we would get rid of the log4j-over-slf4j, which is not that commonly used > in libraries anyways, and replace it with the log4j-1.2-api jar. That > prevents slf4j from seeing a logging feedback loop. - Bobby > > > On Monday, February 9, 2015 12:18 PM, Michael Rose > <[email protected]> wrote: > > > 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 RoseSenior Platform EngineerFullContact | fullcontact.comm: > +1.720.837.1357 | t: @xorlev > > All Your Contacts, Updated and In One Place.Try FullContact for Free > 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 >>> >>> >>> >> > > > > > >
