[
https://issues.apache.org/jira/browse/LOG4J2-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154149#comment-16154149
]
jncharpin edited comment on LOG4J2-2030 at 9/5/17 7:14 PM:
-----------------------------------------------------------
This is the stack trace where Log4jInvoker, simply doing a
Configurator.setLevel(), is loaded from an isolated classloader, containing
log4j jars. Otherwise there is no log4j jlibs part of the classpath.
{{Caused by: java.lang.ClassCastException:
org.apache.logging.log4j.simple.SimpleLoggerContext cannot be cast to
org.apache.logging.log4j.core.LoggerContext
at
org.apache.logging.log4j.core.LoggerContext.getContext(LoggerContext.java:190)
at
org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:291)
at com.util.Log4jInvoker.doIt(Log4jInvoker.java:11)}}
The point is that the ServiceLoader doesn't find the ServiceProvider, then the
search is still performed with the PROVIDER_RESOURCE on each classloader,
including the URLClassloader above, but the PROVIDER_RESOURCE is missing in
2.9.0 jar.
Wondering if same ServiceLoader should be performed on each "candidates" rather
than this getResources.
{{private ProviderUtil() {
loadProviders(findClassLoader());
for (final LoaderUtil.UrlResource resource :
LoaderUtil.findUrlResources(PROVIDER_RESOURCE)) {
loadProvider(resource.getUrl(), resource.getClassLoader());
}
}
final ClassLoader[] candidates = {getThreadContextClassLoader(),
*LoaderUtil.class.getClassLoader()*,
GET_CLASS_LOADER_DISABLED ? null :
ClassLoader.getSystemClassLoader()};
}}
was (Author: jncharpin):
This is the stack trace where Log4jInvoker, simply doing a
Configurator.setLevel(), is loaded from an isolated classloader, containing
log4j jars. Otherwise there is no log4j jlibs part of the classpath.
{{Caused by: java.lang.ClassCastException:
org.apache.logging.log4j.simple.SimpleLoggerContext cannot be cast to
org.apache.logging.log4j.core.LoggerContext
at
org.apache.logging.log4j.core.LoggerContext.getContext(LoggerContext.java:190)
at
org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:291)
at com.util.Log4jInvoker.doIt(Log4jInvoker.java:11)}}
The point is that the ServiceLoader doesn't find the ServiceProvider, then the
search is still performed with the PROVIDER_RESOURCE on each classloader,
including the URLClassloader above, but the PROVIDER_RESOURCE is missing in
2.9.0 jar.
Wondering if same ServiceLoader should be performed on each "candidates" rather
than this getResources.
{{ private ProviderUtil() {
loadProviders(findClassLoader());
for (final LoaderUtil.UrlResource resource :
LoaderUtil.findUrlResources(PROVIDER_RESOURCE)) {
loadProvider(resource.getUrl(), resource.getClassLoader());
}
}}}
{{ final ClassLoader[] candidates = {getThreadContextClassLoader(),
*LoaderUtil.class.getClassLoader()*,
GET_CLASS_LOADER_DISABLED ? null :
ClassLoader.getSystemClassLoader()};}}
> ClassCastException: org.apache.logging.log4j.simple.SimpleLoggerContext
> cannot be cast to org.apache.logging.log4j.core.LoggerContext
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LOG4J2-2030
> URL: https://issues.apache.org/jira/browse/LOG4J2-2030
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.9.0
> Reporter: jncharpin
>
> When upgrading from 2.8.2 to 2.9.0, we are facing the following exception
> when accessing the context.
> Caused by: java.lang.ClassCastException:
> org.apache.logging.log4j.simple.SimpleLoggerContext cannot be cast to
> org.apache.logging.log4j.core.LoggerContext
> at
> org.apache.logging.log4j.core.LoggerContext.getContext(LoggerContext.java:190)
> at
> org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:291)
> Seems like that the context factory is incorrect and defaulted to
> {{SimpleLoggerContextFactory}} because of the provider is not able to find
> the resource {{META-INF/log4j-provider.properties}} which is missing in 2.9.0
> if not wrong.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
