The critical feature is putting a cap on the total size of log files kept for a worker. As long as log4j2 allows you to put a hard limit (e.g. 1GB total across all log files for a worker, with older files being deleted as limit is exceeded), then I don't mind switching.
On Mon, Feb 9, 2015 at 9: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 > > > > > > > > > > > > > > > -- Twitter: @nathanmarz http://nathanmarz.com
