[
https://issues.apache.org/jira/browse/LOG4J2-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006253#comment-17006253
]
ASF subversion and git services commented on LOG4J2-2754:
---------------------------------------------------------
Commit 8ef2b34105b33869a983b0be3256b7cf59febaed in logging-log4j2's branch
refs/heads/release-2.x from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=8ef2b34 ]
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: 40m
> 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)
