[
https://issues.apache.org/jira/browse/LOG4J2-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006256#comment-17006256
]
ASF subversion and git services commented on LOG4J2-2754:
---------------------------------------------------------
Commit 0db2bbb948dd7e13749efa2b47891678b71f25d3 in logging-log4j2's branch
refs/heads/master from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=0db2bbb ]
LOG4J2-2754: LoaderUtil.getClassLoaders may discover additional loaders
The utility no longer erroneously returns a result with a null element in some
environments.
Also updated loadClass to avoid internally throwing and catching a null
pointer exception when getThreadContextClassLoader returns null.
> LoaderUtil.getClassLoaders fails to update loop state
> -----------------------------------------------------
>
> Key: LOG4J2-2754
> URL: https://issues.apache.org/jira/browse/LOG4J2-2754
> Project: Log4j 2
> Issue Type: Bug
> Affects Versions: 2.13.0
> Reporter: Carter Kozak
> Assignee: Carter Kozak
> Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Same problem as LOG4J2-2104, but for final 'ClassLoader current =
> LoaderUtil.class.getClassLoader();'
> The while loop acts as a simple conditional (unless a classloader is defined
> with an incorrect 'equals' method, then it loops infinitely -- I've not seen
> this behavior in practice though).
> It appears that getThreadContextClassLoader can return a null ClassLoader,
> which ends up in the getClassLoaders result erroneously.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
