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