57

I must be missing something but I have been looking at this for a few days now, but why on earth would you ever use log4j2 over log4j (other than the performance)?

From what I have seen so far, log4j2 is advertised as simpler to configure, but its actually vastly more complicated (been three days now and I still cant get it to write a log in my home directory). The auto configuration simply does not work for me (or at least I cant get it to work), the configuration file itself is substantially more complex in its structure and appears to be much harder to add things in at runtime to help diagnose.

So other than the performance is there any reason to use log4j2 over original log4j?

Remko Popma
  • 35,130
  • 11
  • 92
  • 114
Scott Neville
  • 848
  • 1
  • 7
  • 14
  • I never use either of them. – user207421 May 04 '15 at 01:51
  • 1
    I use SLF4J + Logback :P – Adrian Shum May 04 '15 at 02:27
  • 1
    My personal advise: if you do not know the reason yet, do not upgrade to Log4j2. You will eventually encounter problems or difficulties with plain Log4j after you gain more and more experience. Choose from SLF4J (+ Logback) or Log4j2 at that time and you will know how to do it properly instead of just made confused by the change of configuration (which have no obvious meaning to you yet) – Adrian Shum May 04 '15 at 02:31
  • Been using log4j for about 8 years now, not really run into any problems yet, yeah threading messes with your mind a bit, but grep soon sorts that. – Scott Neville May 04 '15 at 22:32

2 Answers2

84

Reasons to upgrade from Log4j 1.x to Log4j 2

Update: since August 2015, Log4j 1.x is officially End of Life and it is recommended to upgrade to Log4j 2. Update 2: Log4j 1.2 is broken in Java 9.

  • Community support: Log4j 1.x is not actively maintained, whereas Log4j 2 has an active community where questions are answered, features are added and bugs are fixed.
  • Async Loggers - performance similar to logging switched off
  • Custom log levels
  • Automatically reload its configuration upon modification without losing log events while reconfiguring.
  • Java 8-style lambda support for lazy logging
  • Log4j 2 is garbage-free (or at least low-garbage) since version 2.6
  • Filtering: filtering based on context data, markers, regular expressions, and other components in the Log event. Filters can be associated with Loggers. You can use a common Filter class in any of these circumstances.
  • Plugin Architecture - easy to extend by building custom components
  • Supported APIs: SLF4J, Commons Logging, Log4j-1.x and java.util.logging
  • Log4j 2 API separate from the Log4j 2 implementation. API supports more than just logging Strings: CharSequences, Objects and custom Messages. Messages allow support for interesting and complex constructs to be passed through the logging system and be efficiently manipulated. Users are free to create their own Message types and write custom Layouts, Filters and Lookups to manipulate them.
  • Concurrency improvements: log4j2 uses java.util.concurrent libraries to perform locking at the lowest level possible. Log4j-1.x has known deadlock issues.
  • Configuration via XML, JSON, YAML, properties configuration files or programmatically.

Be aware

  • log4j2.xml and log4j2.properties formats are different from the Log4j 1.2 configuration syntax
  • Log4j 2 is not fully compatible with Log4j 1.x: The Log4j 1.2 API is supported by the log4j-1.2-api adapter but customizations that rely on Log4j 1.2 internals may not work.
  • Java 6 required for version 2.0 to 2.3. Java 7 is required for Log4j 2.4 and later.

Tips when upgrading

Common issues people are having when getting started with log4j2:

  • You need (at least) both log4j-api-2.6.2.jar and log4j-core-2.6.2.jar in your classpath
  • Log4j2 looks for a log4j2.xml config file, not a log4j.xml config file
  • Config file location: either put it in the classpath or specify its path with the log4j.configurationFile system property
  • To debug the configuration, use <Configuration status="trace"> in the beginning of your config file
  • I would recommend starting with one of the many sample configurations provided in the log4j2 manual, then add more bells and whistles bit by bit.

If your problem is not one of the above, please show your config and provide more detail on what problem you are experiencing. (Not sure what you expect from auto-configuration, this is a very basic function that logs ERROR events to the console if log4j2 cannot find a configuration file. This will rarely be sufficient.)

To write to your home directory, you can use the system property lookup ${sys:PROPERTYNAME}. Below is an example configuration to demonstrate:

<Configuration status="trace">
  <Properties>
    <Property name="logfile">${sys:user.home}/log${date:yyyyMMdd}.log</Property>
  </Properties>
  <Appenders>
    <Console name="STDOUT" target="SYSTEM_OUT">
      <PatternLayout pattern="%m%n"/>
    </Console>
    <File name="FILE" fileName="${sys:logfile}">
      <PatternLayout>
        <pattern>%d %p [%t] %c{1.} %m%n</pattern>
      </PatternLayout>
    </File>
  </Appenders>
  <Loggers>
    <Root level="trace">
      <AppenderRef ref="STDOUT" level="ERROR" />
      <AppenderRef ref="FILE" />
    </Root>
  </Loggers>
</Configuration>
Remko Popma
  • 35,130
  • 11
  • 92
  • 114
  • See why is that down the bottom of the manual, that explains everything. "sys:", so its not ${user.home} its ${sys:user.home}. Although I still dont get how the XML option is better than the traditional properties file, its just more verbose without adding anything of value (unless of course I cant see the value because there is so much of it there!). – Scott Neville May 04 '15 at 22:39
  • We looked into supporting the .properties format but there are component hierarchies and references that are very hard to express in the flat properties format... – Remko Popma May 05 '15 at 04:05
  • 1
    Properties files are supported in current releases. – rgoers Apr 26 '16 at 21:37
  • @Remko Popma Thank you for such a detailed explanation. Can anyone point me to the log4j 1.x-to-log4j4 2 adapter? I can see JUL and SLF4J adapters, but not that one, although the project page does mention that at adapter is available. I have an old project that uses log4j 1.2, which I don't want to change, and want to reuse ome of the code in a new project I'm writing, for which I'm considering log4j 2. – biggvsdiccvs Feb 03 '17 at 10:31
  • Sure. It's the log4j-1.2-api module. This allows you to use the old API in your application and use the log4j2 backend for logging. – Remko Popma Feb 03 '17 at 12:50
  • @RemkoPopma - Could you please suggest some tutorial to learn log4j2 logging for a beginner who never did any logging before ? Is it ok to learn from an old log4j book and then read a log4j2 tutorial ? – MasterJoe Jul 19 '17 at 19:13
  • The book should cover the principles, like when to log, what to log, what log levels are commonly used for which purpose etc. The actual mechanics of logging will differ per library. A book will likely give you deeper insight, go for it. Some of the tutorials here may be useful: https://logging.apache.org/log4j/2.x/articles.html – Remko Popma Jul 19 '17 at 23:11
  • Very concise answer, thanks :) – Azim Aug 11 '17 at 11:51
  • @RemkoPopma Thank you, but can we use
    attribute inside for custom header at the start of log ?
     – Opu Feb 10 '21 at 07:35
9

Check this. In short, from the link:

Log4j 2.0 introduces:

  • a new plugin system

  • support for properties

  • support for JSON-based configuration and automatic reloading of its configuration.

Support for many existing logging frameworks, including SLF4J, Commons Logging, Apache Flume and Log4j 1.x, and provides a new programmer’s API.

As you said it's also much faster.

Disadvantages are:

  • log4j 2.0 is very different than log4j 1.x, and the API is mostly incompatible.

  • Difficult to set up.

If you don't need any of the new features, you're probably fine with the older Log4j 1.x.

Community
  • 1
  • 1
Jonas Czech
  • 12,018
  • 6
  • 44
  • 65
  • 1
    Note that I was able to switch to Log4j2 easily in a complex project; configuration migrates without changes although it is better to switch to the new xml syntax; it has more options to satisfy the advanced; auto detecting changes life at runtime is now simpler; and probably you do want to switch to the new version. One of the benefits is the asynchronous logging support. – YoYo May 04 '15 at 02:12
  • 1
    YoYo switching is easy ???? In our project, we have extended a lot of classes to migrate that ti log4j2 is a nightmare. Documentation is so poor. For example, Appender no longer has a threshold how do you know how to replace that is it by adding a filter or something how do you know what to replace with what? Migration steps are 1 paragraph. !!!! – Radoslav Nov 25 '18 at 11:47