[
https://issues.apache.org/jira/browse/LOG4J2-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker resolved LOG4J2-2934.
---------------------------------
Fix Version/s: 3.0.0
Assignee: Piotr Karwasz
Resolution: Fixed
This was fixed back in September when Piotr configured BND in the build. We now
rely on SPI Fly for general use, and Pax-Logging for lower level use which can
add OSGi-specific customizations.
> Under OSGi log4j-api almost never binds to a Provider (e.g. from log4j-core)
> ----------------------------------------------------------------------------
>
> Key: LOG4J2-2934
> URL: https://issues.apache.org/jira/browse/LOG4J2-2934
> Project: Log4j 2
> Issue Type: Bug
> Components: API
> Reporter: Todor Boev
> Assignee: Piotr Karwasz
> Priority: Major
> Fix For: 3.0.0
>
>
> The log4j-api is has BundleActivator that has to obtain a lock provided by
> ProviderUtil so that it can block the binding of a Provider until one becomes
> available from another bundle.
> At the same time when the first class load request hits LogManager it runs a
> static code block that ultimately calls ProviderUtil to get a Provider by
> also obtaining the lock first. Except in this case if a provider is not
> available the lock is released and SimpleLoginContextFactory is bound from
> now on.
> There is a race condition between these two execution flows. If the
> BundleActivator manages to get the lock first the correct Provider will be
> used with it's LoginContextFactory. If the thread that triggers a class load
> of LogManager manages to grab the lock first the SimpleLoginContextFactory
> will be used.
> There is no predictable way to order this execution. It is sufficient for any
> arbitrary bundle to load a class that has a static Logger field before
> log4j-api is started to break the Provider binding. In almost all cases the
> wrong Provider is bound. Basically this part of the OSGi integration of Log4j
> 2 has to be completely bypassed using various hacks to get the non-OSGi way
> to bind a Provider to work.
> The correct way to fix this is for ProviderUtil to check whether it runs
> under OSGi and if so to block unconditionally waiting for a Provider to be
> supplied. Such a check is usually done in a static block by attempting to
> class load via reflection something from the core OSGi API.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
