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 > > >
