[
https://issues.apache.org/jira/browse/LOG4J2-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17446276#comment-17446276
]
David commented on LOG4J2-3193:
-------------------------------
I think that's part of it. Do you think it makes sense to declare the TreeSet
with "new PropertySource.Comparator().reversed()" rather than change the
behavior of the comparator itself? I'm not sure how else that Comparator is
used.
I don't think that's the whole problem I was seeing though. When my debugger
gets to ConfigurationFactory$Factory.getConfiguration, and it executes:
{code:java}
final String configLocationStr =
this.substitutor.replace(PropertiesUtil.getProperties()
.getStringProperty(CONFIGURATION_FILE_PROPERTY));{code}
The PropertiesUtil instance has both of these values in its normalized map:
* log4j2.configurationFile=bad.xml
* LOG4J_CONFIGURATION_FILE=good.xml
Because the key from the environment variable is 'normalized' differently, it
can't override the key from the PropertiesPropertySource no matter what order
they go in. Then getConfiguration specifically looks up
'log4j.configurationFile' so it can never see the key from the
EnvironmentPropertySource.
The 'tokenized' map ends up with only one entry, but it is checked last by
PropertiesUtil$Environment.get so the value from 'normalized' always wins. The
value in 'tokenized' is the (wrong) property value, but that would be fixed by
reversing the TreeSet as you mentioned. Would it make sense for
PropertiesUtil$Environment.get to check 'tokenized' first?
> ConfigurationFactory cannot find config file property normalized by
> EnvironmentPropertySource
> ---------------------------------------------------------------------------------------------
>
> Key: LOG4J2-3193
> URL: https://issues.apache.org/jira/browse/LOG4J2-3193
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 2.14.1
> Reporter: David
> Priority: Major
>
> I am setting `LOG4J_CONFIGURATION_FILE` as an environment variable, and also
> have a `log4j2.component.properties` file that specifies a different value
> for `log4j2.configurationFile`.
> When `PropertyUtils$Environment.reload` [handles each key value pair and
> normalizes the
> key|https://github.com/apache/logging-log4j2/blob/rel/2.14.1/log4j-api/src/main/java/org/apache/logging/log4j/util/PropertiesUtil.java#L466],
> `EnvironmentPropertySource.getNormalForm` [normalizes the environment
> variable|https://github.com/apache/logging-log4j2/blob/rel/2.14.1/log4j-api/src/main/java/org/apache/logging/log4j/util/EnvironmentPropertySource.java#L61]
> to `LOG4J_CONFIGURATION_FILE` but `PropertiesPropertySource.getNormalForm`
> [normalizes the property from the
> file|https://github.com/apache/logging-log4j2/blob/rel/2.14.1/log4j-api/src/main/java/org/apache/logging/log4j/util/PropertiesPropertySource.java#L52]
> as `log4j2.configurationFile`. So _both_ values end up in the `normalized`
> Map.
> Then when `ConfigurationFactory` [gets the configuration file
> property|https://github.com/apache/logging-log4j2/blob/rel/2.14.1/log4j-core/src/main/java/org/apache/logging/log4j/core/config/ConfigurationFactory.java#L398]
> it only looks for `log4j.configurationFile` and ignores the
> LOG4J_CONFIGURATION_FILE environment variable.
> This seems to contradict the
> [documentation|https://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties]
> which says that environment variables should take precedence over properties
> files.
> If I'm not mistaken and this is truly a bug, then I'd be happy to work on a
> PR if it would get it resolved more quickly. I would just need some guidance
> about the proper solution. Should `EnvironmentPropertySource.getNormalForm`
> be updated to produce the same style output as
> `PropertyPropertySource.getNormalForm`? The [tests
> indicate|https://github.com/apache/logging-log4j2/blob/rel/2.14.1/log4j-api/src/test/java/org/apache/logging/log4j/util/EnvironmentPropertySourceTest.java#L43]
> that the current behavior is not an accident, so I'm unsure what ought to be
> done.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
