[
https://issues.apache.org/jira/browse/LOG4J2-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-1532:
---------------------------------
Description:
Don't throw an NPE from
{{org.apache.logging.log4j.core.LoggerContext.setConfiguration(Configuration)}}
when the configuration is missing.
I am seeing this in a customer use case with what the customer says is version
"2.6.x."
The method
{{org.apache.logging.log4j.core.LoggerContext.setConfiguration(Configuration)}}
throws an exception when the given {{Configuration}} is null.
This can happen when the method is called by
{{org.apache.logging.log4j.core.LoggerContext.reconfigure(URI)}} and the file
backing the URI has disappeared.
Thoughts?
I propose that we either:
# Log an ERROR from
{{org.apache.logging.log4j.core.LoggerContext.setConfiguration(Configuration)}}
instead of throwing an NPE; or
# Change the implementation of
{{org.apache.logging.log4j.core.LoggerContext.reconfigure(URI)}} to check for a
null answer from
{{ConfigurationFactory.getInstance().getConfiguration(contextName, configURI,
cl);}} and log an ERROR if null.
# Do both (the best IMO.)
The exception I've see is (I had to change some class names and package names):
{noformat}
> Name: java.lang.NullPointerException
> Message: No Configuration was provided
> StackTrace: java.util.Objects.requireNonNull(Objects.java:228)
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:477)
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:561)
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:577)
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:212)
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> com.example.log.MyLoggerHelperFactory.getLoggerContext(MyLoggerHelperFactory.java:79)
> com.example.log.MyLoggerHelperFactory.getFormatterLogger(MyLoggerHelperFactory.java:73)
> com.example.log.MyLoggerHelperFactory.getFormatterLogger(MyLoggerHelperFactory.java:68)
> com.example.MyLoggerHelper.<init>(MyLoggerHelper.java:67)
> com.example.MyLoggerHelper.<init>(MyLoggerHelper.java:57)
> com.example.MyAbstractObject.<init>(MyAbstractObject.java:27)
> com.example.MyMain.<init>(MyMain.java:125)
> com.example.MyMain.<clinit>(MyMain.java:24)
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
{noformat}
was:
Don't throw an NPE from
{{org.apache.logging.log4j.core.LoggerContext.setConfiguration(Configuration)}}
when the configuration is missing.
I am seeing this in a customer use case with what the customer says is version
"2.6.x."
The method
{{org.apache.logging.log4j.core.LoggerContext.setConfiguration(Configuration)}}
throws an exception when the given {{Configuration}} is null.
This can happen when the method is called by
{{org.apache.logging.log4j.core.LoggerContext.reconfigure(URI)}} and the file
backing the URI has disappeared.
Thoughts?
I propose that we either:
# Log an ERROR from
{{org.apache.logging.log4j.core.LoggerContext.setConfiguration(Configuration)}}
instead of throwing an NPE; or
# Change the implementation of
{{org.apache.logging.log4j.core.LoggerContext.reconfigure(URI)}} to check for a
null answer from
{{ConfigurationFactory.getInstance().getConfiguration(contextName, configURI,
cl);}} and log an ERROR if null.
# Do both (the best IMO.)
> Don't throw an NPE from
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(Configuration)
> when the configuration is missing
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LOG4J2-1532
> URL: https://issues.apache.org/jira/browse/LOG4J2-1532
> Project: Log4j 2
> Issue Type: Improvement
> Components: Configurators
> Affects Versions: 2.6, 2.6.1, 2.6.2
> Reporter: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> Don't throw an NPE from
> {{org.apache.logging.log4j.core.LoggerContext.setConfiguration(Configuration)}}
> when the configuration is missing.
> I am seeing this in a customer use case with what the customer says is
> version "2.6.x."
> The method
> {{org.apache.logging.log4j.core.LoggerContext.setConfiguration(Configuration)}}
> throws an exception when the given {{Configuration}} is null.
> This can happen when the method is called by
> {{org.apache.logging.log4j.core.LoggerContext.reconfigure(URI)}} and the file
> backing the URI has disappeared.
> Thoughts?
> I propose that we either:
> # Log an ERROR from
> {{org.apache.logging.log4j.core.LoggerContext.setConfiguration(Configuration)}}
> instead of throwing an NPE; or
> # Change the implementation of
> {{org.apache.logging.log4j.core.LoggerContext.reconfigure(URI)}} to check for
> a null answer from
> {{ConfigurationFactory.getInstance().getConfiguration(contextName, configURI,
> cl);}} and log an ERROR if null.
> # Do both (the best IMO.)
>
> The exception I've see is (I had to change some class names and package
> names):
> {noformat}
> > Name: java.lang.NullPointerException
> > Message: No Configuration was provided
> > StackTrace: java.util.Objects.requireNonNull(Objects.java:228)
> > org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:477)
> > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:561)
> > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:577)
> > org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:212)
> > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> > org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> > org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> > com.example.log.MyLoggerHelperFactory.getLoggerContext(MyLoggerHelperFactory.java:79)
> > com.example.log.MyLoggerHelperFactory.getFormatterLogger(MyLoggerHelperFactory.java:73)
> > com.example.log.MyLoggerHelperFactory.getFormatterLogger(MyLoggerHelperFactory.java:68)
> > com.example.MyLoggerHelper.<init>(MyLoggerHelper.java:67)
> > com.example.MyLoggerHelper.<init>(MyLoggerHelper.java:57)
> > com.example.MyAbstractObject.<init>(MyAbstractObject.java:27)
> > com.example.MyMain.<init>(MyMain.java:125)
> > com.example.MyMain.<clinit>(MyMain.java:24)
> > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
