Versions Compared

Old Version 1

changes.mady.by.user Matt Sicker

Saved on

compared with

New Version Current

changes.mady.by.user Piotr Karwasz

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Log4j 2.x has a fairly complex API initialization process. Log4j 3.x intends to simplify and unify this into a proper SPI.

Overview of 2.23.0 API Initialization

In Log4j 2.23.0 and later the Log4j API subsystems are initialized roughly in this order:

  1. StatusLogger  and AbstractLogger are initialized with some dependent classes like MarkerManager . These classes of course can not call StatusLogger.getLogger() in their static initialization block nor use PropertiesUtil ,
  2. The classloading subsystem is started: LoaderUtil , ServiceLoaderUtil , OsgiServiceLocator and StackLocatorUtil . These can use StatusLogger , but can not use PropertiesUtil  in their static initialization block,
  3. PropertiesUtil  is initialized,
  4. The other services are initialized and the system should pretty much be stable.

Overview of older 2.x API Initialization

Typical usage of Log4j begins with use of either LogManager or ThreadContext. The expectation is that Log4j will be initialized and ready to use as soon as user code calls LogManager::getLogger or similar. This introduces a hierarchy of dependent classes for initialization.

...