Yes, I agree we definitely should keep slf4j. And good point; I will send mail to the users list too.
> If the only reason is to have a RFC5424-compliant syslog appender, why not > fix logback's or build a separate one? When I looked around, I saw a very old patch to logback that would add or fix syslog appender. The size of the patch in lines of code was in the thousands, and it was not clear anyone had done anything to merge it in since around 2004. There are also a couple of logback JIRA issues open for doing proper syslog, but they are pretty stale. So it seemed to me the move to log4j2 would be an upgrade for the storm project and a lot less work than either fixing logback's appender or building our own appender. I'd be happy to be wrong though. -- Derek ----- Original Message ----- From: P. Taylor Goetz <[email protected]> To: "[email protected]" <[email protected]> Cc: Michael Rose <[email protected]> Sent: Monday, February 9, 2015 7:40 PM Subject: Re: [DISCUSS] Logging framework logback -> log4j 2.x 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 >>> >>> >>> >> > > > > > >
