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:
StatusLogger
andAbstractLogger
are initialized with some dependent classes likeMarkerManager
. These classes of course can not callStatusLogger.getLogger()
in their static initialization block nor usePropertiesUtil
,- The classloading subsystem is started:
LoaderUtil
,ServiceLoaderUtil
,OsgiServiceLocator
andStackLocatorUtil
. These can useStatusLogger
, but can not usePropertiesUtil
in their static initialization block, PropertiesUtil
is initialized,- 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.
...