Allow disabling the optimization for filling the stack traces

[neboskreb]

Allow disabling the optimization for filling the stack traces

Description

Utility PrivateSecurityManagerStackTraceUtil offers an optimized way to fill the stack traces. For this it uses SecurityManager.getClassContext() which is faster.

Unfortunately, it is not always possible. On Android security managers are not used. Though class SecurityManager is present in the classpath, it contains just stubs; hence the array returned from getClassContext() is always null.
This results in an NPE when Log4J tries to use it to fill the stack trace.


Fortunately, Log4J library will first check isEnabled() before using this optimization.

Configuration

Version: 2.24.3

Operating system: Android

JDK: not relevant

Logs

Not relevant

Reproduction

Just log an arbitrary exception:

log.warn("test", new Exception());

Solution

For now, the proposed remedy is to allow the developer on Android to explicitly disable this optimization.

A bigger problem is coming later, as java.lang.SecurityManager is deprecated and marked for removal. Once it is removed, the PrivateSecurityManagerStackTraceUtil (who internally extends SecurityManager) will start failing to load on Android. That will require a better mechanism to exclude this optimization from the execution path.

Action points

• To fix the immediate problem: review and merge the proposed PR A way to disable the optimization for filling the stack traces #3638
• For the longer perspective: consider options for the case when class SecurityManager is missing in runtime

[ppkarwasz]

@neboskreb,

Thank you for the report.

PS: In the website for the upcoming 2.25.0 release we added a FAQ entry about Android. Can you add a reference to your Log4j API implementation and explain how it differs from com.celeral:log4j2-android?

[neboskreb]

Can you add a reference to your Log4j API implementation and explain how it differs from com.celeral:log4j2-android?

Sure, will do ASAP!

[neboskreb]

@ppkarwasz

Added a small section. See #3643

[vy]

@ppkarwasz, @neboskreb, I have the impression that #3638 addressing this issue is merged. Can we close this issue?

[neboskreb]

Though the risk that SecurityManager is removed from the runtime remains, the immediate problem on Android is fixed. So I believe yes, #3639 can be happily closed.