Just some feedback, I don't have a particular opinion one way or the other but, this would be problematic for anyone who wrote custom Logback plugins. In the past, I had explored writing a custom Logback plugin to properly handle logs being routed to a daemon, while capturing important provenance information to determine where the log came from (it would attach things like message identifiers to the log messages). If I had done this, Storm switching (back to) Log4j would obviously cause a bit of a headache. Part of this would be accomplished by using an RFC5424 logger, but without looking into it too deeply, I doubt it would satisfy all requirements of this nature, or alleviate the need for all user logger plugins.
On Wed, Feb 11, 2015 at 10:32 AM, Derek Dagit <[email protected]> wrote: > 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 > >>> > >>> > >>> > >> > > > > > > > > > > > > >
