[jira] [Commented] (LOG4J2-1926) Remove dependency on RMI and Management APIs from log4j-api

["Remko Popma (JIRA)" <ji...@apache.org>]

    [ 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)