[
https://issues.apache.org/jira/browse/LOG4J2-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14148950#comment-14148950
]
Michael Sutherland edited comment on LOG4J2-862 at 9/26/14 9:18 AM:
--------------------------------------------------------------------
I did try setting _"-Dlog4j2.StatusLogger.level=TRACE"_ but Log4j2 fails with
the class cast exception before it starts logging anything so it doesn't add
anything to the discussion.
When you say "Looks like ProviderUtil uses the current Thread classloader,
unless the Security Manager restricts the "getClassLoader" privilege, in which
case it uses the classloader of its own class." I don't think I agree, if it
cannot use {code}ThreadContextClassLoaderGetter{code} it uses
{code}ClassLoader.getSystemClassLoader(){code} which is not the same as
{code}ProviderUtil.class.getClassLoader(){code}.
You can see the output from the three different options in the code I quoted
above. In short {code}ClassLoader.getSystemClassLoader(){code} will return an
instance of {code}sun.misc.Launcher$AppClassLoader{code} and
{code}ProviderUtil.class.getClassLoader(){code} will return an instance of
{code}AntClassLoader{code}
How do you do the format for the -DLog4j line? It would make this post much
clearer to read.
was (Author: mike1979):
I did try setting "-Dlog4j2.StatusLogger.level=TRACE" but Log4j2 fails with the
class cast exception before it starts logging anything so it doesn't add
anything to the discussion.
When you say "Looks like ProviderUtil uses the current Thread classloader,
unless the Security Manager restricts the "getClassLoader" privilege, in which
case it uses the classloader of its own class." I don't think I agree, if it
cannot use "ThreadContextClassLoaderGetter" it uses
"ClassLoader.getSystemClassLoader()" which is not the same as
"ProviderUtil.class.getClassLoader()". You can see the output from the three
different options in the code I quoted above. In short
"ClassLoader.getSystemClassLoader()" will return an instance of
"Launcher$AppClassLoader" and "ProviderUtil.class.getClassLoader()" will return
an instance of "AntClassLoader"
> Misleading error message "Log4j2 could not find a logging implementation.
> Please add log4j-core to the classpath."
> ------------------------------------------------------------------------------------------------------------------
>
> Key: LOG4J2-862
> URL: https://issues.apache.org/jira/browse/LOG4J2-862
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
> Affects Versions: 2.0.2
> Reporter: Michael Sutherland
>
> In the code out put I see
> "ERROR StatusLogger Log4j2 could not find a logging implementation. Please
> add log4j-core to the classpath. Using SimpleLogger to log to the console..."
> followed by "java.lang.ClassCastException:
> org.apache.logging.log4j.simple.SimpleLoggerContext cannot be cast to
> org.apache.logging.log4j.core.LoggerContext" which means core must be on the
> class path as otherwise you couldn't get that class cast execption. At which
> point the application using Log4j2 fails to start.
> The underlying problem is org.apache.logging.log4j.LogManager assuming if
> org.apache.logging.log4j.util.ProviderUtil returns false for hasProviders it
> is because core is not on the classpath. In practice I've found that
> hasProviders can return false because ProviderUtil is using a different
> Classloader than the rest of the application. It cannot find the
> "META-INF/log4j-provider.properties" resource but it is on the class path.
> I think there is a problem with the logic of how the classloaders are chosen
> but I don't understand what Log4j is trying to do here, however I am sure the
> error message is confusing and misleading
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
