[
https://issues.apache.org/jira/browse/LOG4J2-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16061906#comment-16061906
]
ASF subversion and git services commented on LOG4J2-1926:
---------------------------------------------------------
Commit 000899acba05e5b9a2a630d59164ba055553e278 in logging-log4j2's branch
refs/heads/master from rpopma
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=000899a ]
LOG4J2-1926 make interface ThreadInformation public since some implementations
will live in log4j-core
> 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)
