[
https://issues.apache.org/jira/browse/LOG4J2-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032785#comment-16032785
]
Remko Popma commented on LOG4J2-1926:
-------------------------------------
In SortedArrayStringMap we can replace MarshalledObject by a simple byte[]
array representing the marshalled data. That will remove the dependency on the
java.rmi package.
To remove the dependency on the java.lang.management package in
[ThreadDumpMessage|https://github.com/apache/logging-log4j2/blob/dbd2d252a1b4139a9bd9eb213c89f28498db6dcf/log4j-api/src/main/java/org/apache/logging/log4j/message/ThreadDumpMessage.java]
and
[ExtendedThreadInformation|https://github.com/apache/logging-log4j2/blob/dbd2d252a1b4139a9bd9eb213c89f28498db6dcf/log4j-api/src/main/java/org/apache/logging/log4j/message/ExtendedThreadInformation.java]
there are a few options:
# Use reflection when using the classes in java.lang.management. On Android,
only provide BasicThreadInfo.
# Move ThreadDumpMessage out of log4j-api entirely.
# Keep ThreadDumpMessage in log4j-api but reduce functionality to always only
provide BasicThreadInfo. Delete ExtendedThreadInformation.
# Keep ThreadDumpMessage in log4j-api but move ExtendedThreadInformation and
other logic that uses java.lang.management into log4j-core. Provide some
mechanism (service provider?) to load this functionality from log4j-core.
I suspect it will be hard to convince anyone in the Log4j 2 community to break
binary compatibility in the log4j-api so I doubt that option 2 is realistic. 3
seems a bit last resort. 1 or 4 seem doable. Thoughts anyone?
> Remove dependency on RMI and Management APIs from log4j-api
> -----------------------------------------------------------
>
> Key: LOG4J2-1926
> URL: https://issues.apache.org/jira/browse/LOG4J2-1926
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.8
> Environment: Android
> Reporter: Oleg Kalnichevski
> Assignee: Remko Popma
>
> (Remko: Paraphrasing discussion on the log4j dev mailing list. Please feel
> free to update/modify):
> When the Apache HttpClient 5.0 library gets pulled into an Android project,
> the Lint static code analyzer reports two severe violations due to transitive
> dependency through Log4j APIs 2.8 on Java RMI and Java Management APIs.
> At the moment adding a transitive dependency on log4j2-api causes any Android
> build to fail with a scary invalid package error. Surely this error can be
> ignored with a custom lint rule but it may present a certain reason for
> concert to less experienced developers.
> This is caused by Log4j's use of MarshalledObject: User domain objects and
> exceptions are wrapped in MarshalledObject when LogEvents are serialized.
> This allows applications like Lilith to deserialize LogEvents even when not
> all domain classes are on the classpath (LOG4J2-1226).
> Consider finding a different way to solve this problem that does not require
> MarshalledObject.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
