You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Krzysztof Gąsior (Jira)" <ji...@apache.org> on 2021/10/27 22:46:00 UTC

[jira] [Comment Edited] (LOG4J2-3181) When custom configurationFile is missing then no fallback configuration is used

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

Krzysztof Gąsior edited comment on LOG4J2-3181 at 10/27/21, 10:45 PM:
----------------------------------------------------------------------

looking at the recent (2.14.1) code, problem is there too: [https://github.com/apache/logging-log4j2/blob/rel/2.14.1/log4j-core/src/main/java/org/apache/logging/log4j/core/config/ConfigurationFactory.java#L394]

I think the simplest fix would be extracting part handling `configurationFile` property into separate function and if it returns null then move towards code which works if this property is not provided, otherwise return the result.

Also it seems that there is an improvement in case of multiple configs (as it would handle missing files) but:
 * if all files would fail it would throw EX on (as configs would be empty then)

{code:java}
                                } else if (configs.size() == 1) {
                                    return configs.get(0);
                                }
{code}
 *  if config would not be instance of `AbstractConfiguration` then again it returns null instead to handle


was (Author: kg):
looking at the recent (2.14.1) code, problem is there too: [https://github.com/apache/logging-log4j2/blob/rel/2.14.1/log4j-core/src/main/java/org/apache/logging/log4j/core/config/ConfigurationFactory.java#L394]

I think the simplest fix would be extracting part handling `configurationFile` property into separate function and if it returns null then move towards code which works if this property is not provided, otherwise return the result. 

Also it seems that there is an improvement in case of multiple configs (as it would handle missing files) but:
 - if all files would fail it would throw EX on (as configs would be empty then)
{code:java}
                                } else if (configs.size() == 1) {
                                    return configs.get(0);
                                }
{code}
- if config would not be instance of `AbstractConfiguration` then again it returns null instead to handle

 

> When custom configurationFile is missing then no fallback configuration is used
> -------------------------------------------------------------------------------
>
>                 Key: LOG4J2-3181
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-3181
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Configuration
>    Affects Versions: 2.13.0
>            Reporter: Krzysztof Gąsior
>            Assignee: Ralph Goers
>            Priority: Major
>
> So I am using following setting to define 'external' logger configuration file
> {code:java}
> -Dlog4j.configurationFile=/etc/xxx/log4j2.properties
> {code}
> I also put a default config inside the package with assumption to use it as a fallback, however if the 'external' configuration file does not exist following occurs:
> {code:java}
> ERROR StatusLogger File not found in file system or classpath: /etc/xxx/log4j2.properties
> ERROR StatusLogger Reconfiguration failed: No configuration found for '27bc2616' at 'null' in 'null'{code}
> and as a result logger is not configured at all and not logging anything, despite the fallback config is inside the package. There is a similar problem described in following [SO ticket|https://stackoverflow.com/questions/58338411/how-to-fall-back-to-log4j2-xml-when-custom-configurationfile-is-missing]
> In such situation I would expect log4j2 to follow the automatic configuration path as defined here: [https://logging.apache.org/log4j/2.x/manual/configuration.html]
>  and use properties from class path or if those not found to fallback to a default settings. If not as a default behavior there at least should be way to force it to work that way.
> Note that there is also a second issue, if define multiple configs via configurationFile, even if single of those fails to be found then same issue as above happens, and we get no configuration at all.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)