Regression in Log4j 2.22.0 on Android because of changes to getThreadContextClassLoader() in LoaderUtil

[centic9]

Description

When upgrading an Android Application which has a transitive dependency on Log4j from log4j-core 2.21.1 to 2.22.0, it fails with an exception because it seems the method AccessController.doPrivileged() with the required parameters is not available on Android, but calls to it are introduced in LoaderUtil now via commit 80de816

This prevents us from upgrading log4j when including any Java libraries which depend on log4j-core in an Android application.

Is it possible to not introduce these changes in the 2.x series? The commit-message sounds like this was sort of "let's backport some stuff from 3.x branches".

Configuration

Version: 2.22.0

Operating system: Android application with min SDK Level 26

JDK: Android

Logs

java.lang.NoSuchMethodError: No static method doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;[Ljava/security/Permission;)Ljava/lang/Object; in class Ljava/security/AccessController; or its super classes (declaration of 'java.security.AccessController' appears in /system/framework/core-oj.jar)
at org.apache.logging.log4j.util.LoaderUtil.getThreadContextClassLoader(LoaderUtil.java:155)
at org.apache.logging.log4j.util.LoaderUtil.findUrlResources(LoaderUtil.java:473)
at org.apache.logging.log4j.util.LoaderUtil.findResources(LoaderUtil.java:462)
at org.apache.logging.log4j.util.PropertyFilePropertySource.loadPropertiesFile(PropertyFilePropertySource.java:45)
at org.apache.logging.log4j.util.PropertyFilePropertySource.<init>(PropertyFilePropertySource.java:37)
at org.apache.logging.log4j.util.PropertiesUtil.<init>(PropertiesUtil.java:84)
at org.apache.logging.log4j.util.PropertiesUtil.<init>(PropertiesUtil.java:80)
at org.apache.logging.log4j.status.StatusLogger.<clinit>(StatusLogger.java:76)
at org.apache.logging.log4j.status.StatusLogger.getLogger(StatusLogger.java:149)
at org.apache.logging.log4j.LogManager.<clinit>(LogManager.java:60)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:610)
at org.dstadler.poiandroidtest.poitest.ApplicationTest.<clinit>(ApplicationTest.java:17)

Reproduction

Can only be reproduced in Android applications using the Emulator.

There is a sample Android application "poi-on-android" which shows the issue:

• See the following branch for the test-failure with 2.22.0: https://github.com/centic9/poi-on-android/tree/exception_with_log4j_2_22_0 => Fails to run tests via Github Actions, e.g. https://github.com/centic9/poi-on-android/actions/runs/7331541081/job/19964336406
• See the following commit for the same sources except the newer log4j: centic9/poi-on-android@bbea240 => Successfully runs tests via Github Actions, e.g. https://github.com/centic9/poi-on-android/actions/runs/7331536562/job/19964325253

[centic9]

In order to provide a minimal reproducer I have prepared a branch at https://github.com/centic9/poi-on-android/tree/log4j_2_22_0_minimal_reproducer which is a minimal Android Application, upgraded to latest SDK level 34, which still shows the issue when either tests are executed or the resulting Android application is started.

[centic9]

Hi, Yes I know the sad state of some differences between Java on Android and JDK classes, however a lot of code can be used in both worlds currently. It was working up to log4j 2.21.1, probably without any specific effort being put into enabling it. As log4j is used in many third party libraries, some of which try to support running on Android, log4j is often dragged in as transitive dependency. The regression in newer versions will likely make it harder for all these libraries to provide support, maybe at sometime to a level which forces them to use a different logging framework as there is no workaround as far as I see. As the breaking changes do not look absolutely necessary based on the commit-message, you might want to consider doing a minimal revert so it can again be used in this way? Thanks... Dominik.

…

On Thu, Dec 28, 2023 at 11:32 AM Joe ***@***.***> wrote: @centic9 <https://github.com/centic9> Does log4j2 support Android environments? I think it's not. Android SDK API 34 is compatible with OpenJDK some class,not all classes. — Reply to this email directly, view it on GitHub <#2129 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEF3YT755SW25A2FAEXWDDYLVDDRAVCNFSM6AAAAABBDQA6ZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRGAZTONBTGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ppkarwasz]

Hi @centic9,

Thank You for Your issue report.

Is it possible to not introduce these changes in the 2.x series? The commit-message sounds like this was sort of "let's backport some stuff from 3.x branches".

That is the idea: we don't introduce breaking changes in 2.x. On the other hand we try to keep the two branches in sync, which helps backporting bug fixes from main to 2.x. The issue you pointed out is clearly a bug and we'll fix it.

Thank you for your Android test. If you agree, we'll add it to our test suite, so that we prevent this kind of problems in the future.

[centic9]

Thanks for the explanation. Feel free to take from the reproducer whatever is useful.

[jvz]

We should probably just remove the SecurityManager support here, too, as we did in main.

[ppkarwasz]

We should probably just remove the SecurityManager support here, too, as we did in main.

No, Matt, we can't. Wildfly still supports SecurityManager and expects Log4j 2.x to also support it.

Since we are struggling to support OSGi, JPMS, SecurityManager, Android and GraalVM and each of them has its own limitations, I would just propose to use Review-then-Commit on everything that concerns ServiceLoader, OSGi, and SecurityManager in 2.x, read: we don't change it unless it is broken. I have introduced and fixed enough bugs in these areas to know it is a minefield.

@centic9: Matt is working on removing SecurityManager entirely from 3.x. It should be ready in one of the next betas. Before we release it, could we ask you to check its compatibility with Android?

[jvz]

No problem keeping support for SecurityManager. Just requires additional refactoring ;)

[jvz]

This bug appears to be yet another sign that Android's version of Java 8 is non-standard. As the security manager stuff is only relevant when one is installed, I think this class just needs to skip the AccessController::doPrivileged wrapper when no security manager is installed.

[tcmot]

Hi, all

Android SDK is not fully compatible with Openjdk. If you want Android to use log4j2, you need to remove the Openjdk API used in log4j2, which does not exist in Android SDK.