[
https://issues.apache.org/jira/browse/LOG4J2-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16061765#comment-16061765
]
Remko Popma commented on LOG4J2-1926:
-------------------------------------
Getting back to the topic of this ticket, I have given it some more thought and
I think the following would be a clean solution:
* move ExtendedThreadInformation to log4j-core
* make inner interface {{ThreadDumpMessage.ThreadInfoFactory}} public
* make inner class {{ThreadDumpMessage.ExtendedThreadInfoFactory}} a top-level
class and move it to log4j-core
* change ThreadDumpMessage to use the standard service provider extension
mechanism to look up the ThreadInfoFactory. If ExtendedThreadInfoFactory cannot
be found or instantiated, fall back to BasicThreadInfoFactory, like we do now.
This will push the dependency on {{java.lang.management}} out of log4j-api and
into log4j-core. That should solve the remainder of the problems with using
log4j-api on Android.
> 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.4.14#64029)
