The migration’s impact on the actual codebase should be fairly small, assuming best practices have been followed and the underlying logging framework is properly abstracted, for example, via Simple Logging Facade for Java (Slf4j) APIs.
Logger declaration
This section is only useful in case best practices have not been followed, and the loggers have been instantiated directly rather than through a facade such as the one offered by Slf4j. This would then be the best time to actually adapt the codebase to best practices.
Before (Log4j 1.x)
import org.apache.log4j.Logger; ... private static final Logger LOGGER = Logger.getLogger(MyClass.class);
After (Log4j 2.x + Slf4j API)
import org.slf4j.Logger; import org.slf4j.LoggerFactory; ... private static final Logger LOGGER = LoggerFactory.getLogger(MyClass.class);
Framework extension
It is fairly common, especially for test purposes, to extend the underlying logging framework by implementing custom logging components (such as Appenders) that better serve our purposes. The extension process has changed significantly since Log4j 1.x, relying on different abstractions and offering an annotation-based approach.
See the official Log4j 2.x documentation, Extending Log4j, for more details on how to proceed.
Nested Diagnostic Context
The Log4j 1.x Nested Diagnostic Context (NDC) is still available in Log4j 2.x, but it’s accessible through a different API (ThreadContext) and it’s conceptually mapped to the newer Thread Context Stack. If you were relying on the NDC to store thread-based data, you should now adapt your code to use the ThreadContext calls instead, as explained in the official Log4j 2.x documentation, Thread Context.