logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philipp Knobel (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-1454) CompositeConfiguration fails if one configuration file can't be found
Date Tue, 05 Jul 2016 15:45:11 GMT

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

Philipp Knobel commented on LOG4J2-1454:

Actually considering the capability to reconfigure the configuration at runtime, it might
even make sense to have those non existing files not skipped. It could be that someone creates
them during runtime, which would go unnoticed if we exclude it upfront?
The scenario could look like: You have a cluster of your service which share a common configuration
_a.xml_. _b.json_ is local to each service instance, so in case you need to debug something
on one failing instance you have _b.json_ to allow this during runtime, without influencing
the logging of all other instances as well.

> CompositeConfiguration fails if one configuration file can't be found
> ---------------------------------------------------------------------
>                 Key: LOG4J2-1454
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1454
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Configurators
>    Affects Versions: 2.6
>            Reporter: Philipp Knobel
> Let's assume we have a composite configuration like: _log4j.configurationFile=a.xml,b.json_
. If now any of those configs doesn't exist one will get an exception:
> {noformat}
> 2016-07-05 10:36:49,776 main ERROR File not found in file system or classpath: a.xml
> 2016-07-05 10:36:56,949 main ERROR Failed to created configuration at a.xml
> Exception in thread "main" java.lang.ExceptionInInitializerError
> Caused by: java.lang.NullPointerException: No Configuration was provided
> 	at java.util.Objects.requireNonNull(Objects.java:228)
> 	at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:477)
> 	at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:561)
> 	at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:577)
> 	at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:212)
> 	at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> 	at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> 	at org.apache.logging.log4j.LogManager.getContext(LogManager.java:307)
> 	at org.apache.log4j.Logger$PrivateManager.getContext(Logger.java:59)
> 	at org.apache.log4j.Logger.getLogger(Logger.java:41)
> 	at my.package.Runner<clinit>(Runner.java:38)
> {noformat}
> This is due to this code:
> {code}
>                          for (final String sourceLocation : sources) {
>                             final Configuration config = getConfiguration(sourceLocation.trim());
>                             if (config != null && config instanceof AbstractConfiguration)
>                                 configs.add((AbstractConfiguration) config);
>                             } else {
>                                 LOGGER.error("Failed to created configuration at {}",
>                                 return null;
>                             }
>                         }
> {code}
> This seems wrong to me, as I would consider all configurations except the first one optional
(one could argue that even the first one might be an optional one). Anyway it likely shouldn't
happen that the application is dying with an NPE due to bad log configuration.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message