Yes, I think you're right about this. There really would not be an easy way to avoid this where requirements go beyond what log4j2 itself provides in messaging formats. It would be good if those who might have logback plugins would join the discussion on user@. I really would rather not switch, except that I do not currently see an easier way. -- Derek
----- Original Message ----- From: Jon Logan <[email protected]> To: [email protected]; Derek Dagit <[email protected]> Cc: Sent: Friday, February 13, 2015 7:56 PM Subject: Re: [DISCUSS] Logging framework logback -> log4j 2.x Just some feedback, I don't have a particular opinion one way or the other but, this would be problematic for anyone who wrote custom Logback plugins. In the past, I had explored writing a custom Logback plugin to properly handle logs being routed to a daemon, while capturing important provenance information to determine where the log came from (it would attach things like message identifiers to the log messages). If I had done this, Storm switching (back to) Log4j would obviously cause a bit of a headache. Part of this would be accomplished by using an RFC5424 logger, but without looking into it too deeply, I doubt it would satisfy all requirements of this nature, or alleviate the need for all user logger plugins. On Wed, Feb 11, 2015 at 10:32 AM, Derek Dagit <[email protected]> wrote: > Yes, I agree we definitely should keep slf4j. > > And good point; I will send mail to the users list too. > > > > If the only reason is to have a RFC5424-compliant syslog appender, why > not > > fix logback's or build a separate one? > > When I looked around, I saw a very old patch to logback that would add or > fix syslog appender. The size of the patch in lines of code was in the > thousands, and it was not clear anyone had done anything to merge it in > since around 2004. > > There are also a couple of logback JIRA issues open for doing proper > syslog, but they are pretty stale. > > So it seemed to me the move to log4j2 would be an upgrade for the storm > project and a lot less work than either fixing logback's appender or > building our own appender. I'd be happy to be wrong though. > > -- > Derek > > > > ----- Original Message ----- > From: P. Taylor Goetz <[email protected]> > To: "[email protected]" <[email protected]> > Cc: Michael Rose <[email protected]> > Sent: Monday, February 9, 2015 7:40 PM > Subject: Re: [DISCUSS] Logging framework logback -> log4j 2.x > > I'm okay with switching logging frameworks (I hate most of them equally ;) > ), but I would like to stick with slf4j as the logging api so changes like > this are easy. > > However, we may want to at least consider polling users@, and make sure > the change is well documented. The impact to devs is small, but could have > a much larger impact on users. > > -Taylor > > > > > On Feb 9, 2015, at 1:25 PM, Bobby Evans <[email protected]> > wrote: > > > > 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 < > [email protected]> 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 <[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 > >>> > >>> > >>> > >> > > > > > > > > > > > > >
