# Log4j2 in Production: Standardizing Logging at FINN.no

DevFeed: [Log4j2 in Production: Standardizing Logging at FINN.no](<https://devfeed.tech/articles/log4j2-in-production-making-it-fly-31979.md>)

Original publisher: [Read original article](<https://tech.finn.no2014/07/01/log4j2-in-production-making-it-fly/>)

Author: mick

Published: 2014-07-01T22:17:00Z

Content type: article

Language: en

Sources: [Finn.no](<https://devfeed.tech/sources/finn-no.md>)

Topics: [log4j](<https://devfeed.tech/topics/log4j.md>), [Logging](<https://devfeed.tech/topics/logging.md>), [Java](<https://devfeed.tech/topics/java.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>)

Tags: [concurrency](<https://devfeed.tech/tags/concurrency.md>), [java](<https://devfeed.tech/tags/java.md>), [log4j](<https://devfeed.tech/tags/log4j.md>), [logging](<https://devfeed.tech/tags/logging.md>)

## AI overview

The article describes FINN.no's effort to establish Log4j2 as its common backend logging framework while retaining flexibility in logging abstraction layers. It explains the operational and developer rationale for standardization and the stated reasons for choosing Log4j2 over alternatives, including features, Java concurrency support, performance, and community activity.

## Source excerpt

Now that log4j2 is the predominant logging framework in use at FINN.no why not share the good news with the world and try to provide a summary over the introduction of this exciting new technology into our platform. let's just one logging framework In beginning of September 2013 it became the responsibility of one of our engineering teams to introduce a "best practice for logging" for all of FINN. The proposal put forth was that we can standardise on one backend logging framework while there would be no need to standardise on the abstraction layer directly used in our code. The rationale to not standardising the logging abstractions was... - nearly every codebase, through a tree of dependencies, already includes all the different logging abstraction libraries, so the hard work of configuring them against the chosen logging framework is still required, - the different APIs to the different logging abstractions are not difficult for programmers to go between from one project to another. While the rationale to standardising the logging framework was... - makes life easier for programmers with one documented "best practice" for all, - makes it possible through an in-house library to configure all abstraction layers, creating less configuration for programmers, - makes life easier for operations knowing all jvms log the same way, - makes life easier for operations knowing all log files follow the same format. Log4j2 wins HANDS down Log4j2 was chosen as the logging framework given... - it provided all the features that logback was becoming popular for, - between old log4j and logback it was the only framework that was written in java with modern concurrency (ie not hard synchronised methods/blocks), - it provided a significant performance improvement (1000-10000 times faster) - it consisted of a more active community (logback has been announced as the replacement for the old log4j, but log4j2 saw a new momentum in its apache community). This proposal was checked with a vote by