Bug: Unable to locate configured LoggerContextFactory org.apache.logging.log4j.simple.SimpleLoggerContextFactory

[martinstuder]

sessionInfo() output

sessionInfo()
R version 4.3.3 (2024-02-29)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 24.04.1 LTS

Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.12.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.12.0

locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=de_CH.UTF-8 LC_COLLATE=en_US.UTF-8 LC_MONETARY=de_CH.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=de_CH.UTF-8 LC_NAME=de_CH.UTF-8 LC_ADDRESS=de_CH.UTF-8 LC_TELEPHONE=de_CH.UTF-8 LC_MEASUREMENT=de_CH.UTF-8 LC_IDENTIFICATION=de_CH.UTF-8

time zone: Europe/Zurich
tzcode source: system (glibc)

attached base packages:
[1] stats graphics grDevices utils datasets methods base

other attached packages:
[1] XLConnect_1.1.0

loaded via a namespace (and not attached):
[1] compiler_4.3.3 tools_4.3.3 rstudioapi_0.16.0 rJava_1.0-11

Additional environment information

No response

Description

The default logging configuration currently results in log4j configuration errors to be printed to the console. While the log4j2.system.properties file from the java directory seems to be in effect, log4j does not seem to be able to load org.apache.logging.log4j.simple.SimpleLoggerContextFactory from the log4j-api.jar despite the class from being present.

Expected behavior

No log4j configuration errors should be printed to the console.

How to Reproduce

> library(XLConnect)
> wb <- loadWorkbook("test.xlsx", create = TRUE)
2024-09-23T15:27:43.177433903Z main ERROR Unable to locate configured LoggerContextFactory org.apache.logging.log4j.simple.SimpleLoggerContextFactory
2024-09-23T15:27:43.180710475Z main ERROR Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console...

[spoltier]

Given the last sentence

Using SimpleLogger to log to the console...

The SimpleLogger is indeed still instantiated. This is a regression of #189; possibly the configuration has changed (does not look like it so far) or a bug was introduced as 2.24.0, the next version, introduces logging Providers to replace the context factories.

Edit: there was a change in log4j-api's LoaderUtil.loadClass method between 2.21.1 (previously used version) and 2.23.1 (upgraded with poi 5.3.0)

2.23.1: https://github.com/apache/logging-log4j2/blob/fea2a7116160fb1555d578406444b4fc4f0ef2da/log4j-api/src/main/java/org/apache/logging/log4j/util/LoaderUtil.java#L191-L208

2.21.1: https://github.com/apache/logging-log4j2/blob/e613e9ed71279bb52753a4df810d61c11389df81/log4j-api/src/main/java/org/apache/logging/log4j/util/LoaderUtil.java#L127-L148

Since in the old code, the default class loader is attempted anytime loading from the ThreadContextClassLoader fails, it may make a difference - we may want to try setting log4j.ignoreTCL.

[ppkarwasz]

@spoltier,

There is indeed a problem in the o.a.l.l.util.LoaderUtil class (apache/logging-log4j2#2850): the thread context classloader should never be used to load classes. These objects are often assigned to static fields, so they should not retain classes not accessible to the classloader of o.a.l.l.util.LoaderUtil.

BTW: The preferred way to use SimpleLogger since version 2.24.0 is to use the new log4j.provider property:

-Dlog4j.provider=org.apache.logging.log4j.simple.internal.SimpleProvider

[spoltier]

@ppkarwasz thanks! We'll keep this in mind for when POI upgrades to 2.24.x.
For now using the workaround above.