[
https://issues.apache.org/jira/browse/LOG4J2-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242297#comment-16242297
]
Andrejus Chaliapinas commented on LOG4J2-2104:
----------------------------------------------
Ralph - I think there is another issue, which this one now highlights. Inside
ProviderUtil there is such method:
protected static void loadProviders(final ClassLoader cl)
and then inside private constructor of ProviderUtil we have this part:
for (ClassLoader classLoader : LoaderUtil.getClassLoaders()) {
loadProviders(classLoader);
}
so it looks that intent is to load some Service provider(s) by all returned
clasloaders regardless where Provider.class itself was loaded.
At least for use case I'm working on myself - with v2.9.1 I'm getting part of
stack trace like this:
Caused By: java.util.ServiceConfigurationError:
org.apache.logging.log4j.spi.Provider: Provider
org.apache.logging.log4j.core.impl.Log4jProvider not a subtype
at java.util.ServiceLoader.fail(ServiceLoader.java:239)
at java.util.ServiceLoader.access$300(ServiceLoader.java:185)
at
java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:376)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
But if I do such modification within mentioned
protected static void loadProviders(final ClassLoader cl)
method of ProviderUtil:
if (!cl.equals(Provider.class.getClassLoader())) {
return;
}
then error about "not a subtype" is gone for me at runtime cause it then
assures that classes are loaded within same classloader. Potentially better way
here would be to check if there is proper child-parent hierarchy in place (so
if needed - delegation to parent could work as well) and not just equality of
classloaders.
> LoaderUtil getClassLoaders() method and while loops
> ---------------------------------------------------
>
> Key: LOG4J2-2104
> URL: https://issues.apache.org/jira/browse/LOG4J2-2104
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.9.1
> Reporter: Andrejus Chaliapinas
> Priority: Minor
>
> For v2.9.1 inside org.apache.logging.log4j.util.LoaderUtil and
> getClassLoaders() method we have lines 120-123 as such:
> ClassLoader parent = tcl;
> while (parent != null && !classLoaders.contains(parent)) {
> classLoaders.add(parent);
> }
> where it looks like some getParent() call is either missing or otherwise
> "while" loop is not needed.
> In line 111 tcl classloader already added into list of clasloaders:
> classLoaders.add(tcl);
> Was it an attempt to add all classloaders hierarchy or just some immediate
> parents?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
