[jira] [Created] (LOG4J2-2030) ClassCastException: org.apache.logging.log4j.simple.SimpleLoggerContext cannot be cast to org.apache.logging.log4j.core.LoggerContext

Discussion:

jncharpin (JIRA)

2017-09-05 09:28:00 UTC

Permalink

jncharpin created LOG4J2-2030:
---------------------------------

Summary: 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)

jncharpin (JIRA)

2017-09-05 15:18:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153824#comment-16153824 ]

jncharpin commented on LOG4J2-2030:
-----------------------------------

I just noticed the {{ServiceLoader}} approach in 2.9.0.

The use case above is expecting to load log4 libraries from an isolated classloader and not the thread context classloader.

I'm not sure if I'm missing something or if same logic should / could also apply to all "candidates" classloader, as it was the case when loading the provider from {{log4j-provider.properties}}

Thanks

Post by jncharpin (JIRA)
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)

Gary Gregory (JIRA)

2017-09-05 18:19:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154096#comment-16154096 ]

Gary Gregory commented on LOG4J2-2030:
--------------------------------------

Do you have the stack trace?

--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Ralph Goers (JIRA)

2017-09-05 18:47:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154122#comment-16154122 ]

Ralph Goers commented on LOG4J2-2030:
-------------------------------------

It didn't occur to me to leave the old version of the binding in place. I'd be interested in knowing about your use case so we can figure out how to tell ServiceLoader to use it instead of the ThreadContextClassLoader.

--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

jncharpin (JIRA)

2017-09-05 19:14:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154149#comment-16154149 ]

jncharpin commented on LOG4J2-2030:
-----------------------------------

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()};}}

--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

jncharpin (JIRA)

2017-09-05 19:15:00 UTC

Permalink

[ 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()};}}

--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Gary Gregory (JIRA)

2017-09-05 19:22:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154149#comment-16154149 ]

Gary Gregory edited comment on LOG4J2-2030 at 9/5/17 7:21 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.

{noformat}
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)
{noformat}

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.

{noformat}
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()};
{noformat}

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()};
}}

--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

jncharpin (JIRA)

2017-09-05 19:24:00 UTC

Permalink

[ 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:23 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.

{noformat}
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)
{noformat}

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.

{noformat}
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()};
{noformat}

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.

{noformat}
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)
{noformat}

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.

{noformat}
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()};
{noformat}

--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Ralph Goers (JIRA)

2017-09-05 23:39:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralph Goers reassigned LOG4J2-2030:
-----------------------------------

Assignee: Ralph Goers

Post by jncharpin (JIRA)
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
Assignee: Ralph Goers
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)

Ralph Goers (JIRA)

2017-09-06 06:29:02 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralph Goers resolved LOG4J2-2030.
---------------------------------
Resolution: Fixed
Fix Version/s: 2.9.1

Fixed in master. Please verify and close.

Post by jncharpin (JIRA)
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
Assignee: Ralph Goers
Fix For: 2.9.1
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)

jncharpin (JIRA)

2017-09-06 07:46:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/LOG4J2-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jncharpin closed LOG4J2-2030.
-----------------------------

Verified on 2.9.1-SNAPSHOT built on master.

Thanks

Post by jncharpin (JIRA)
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
Assignee: Ralph Goers
Fix For: 2.9.1
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)