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
<der...@yahoo-inc.com.INVALID> 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
