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
<mich...@fullcontact.com> 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 <ev...@yahoo-inc.com.invalid>
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
<mich...@fullcontact.com> 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 <st...@harsha.io> 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
> > <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
> >
> >
> >
>
