[
https://issues.apache.org/jira/browse/LOG4J2-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488588#comment-17488588
]
Ralph Goers edited comment on LOG4J2-3394 at 2/8/22, 4:51 AM:
--------------------------------------------------------------
The fix Matt did was to process the configuration before any other processing
was done and to replace the single property with the properties the
PropertiesConfiguration already supports. Unfortunately, that requires
resolving any variables specified in the value since the syntax of the value
covers multiple property values so you can't really know what the resolution
will be. For example
{code:java}
log4j.rootLogger=${sys:root.log.level:-INFO}, console
{code}
could be specified and then you could do -Droot.log.level="INFO, file" which,
of course, would result in
{code:java}
log4j.rootLogger=INFO, file, console
{code}
which may, or may not, have been intended. But that is the mess combining
properties this way causes, and which is why I am against using it in any other
syntax. Worse, the fix I added resolved the properties during the preprocessing
but then normal processing would have allowed a second pass at variable
resolution. So if your -D contained another ${sys:...} string it would have
been resolved, which is something we would rather avoid.
The fix I plan on doing will remove the code Matt did and simply resolve the
string as a "normal" property and perform the multiple actions that are
required at that time. This will follow normal property resolution so the
lookups will only be performed once. One other benefit is that the syntax can
be as shown above - log4j.rootLogger=. This syntax is not possible with XML,
Yaml or JSON in Log4j as our XML processing doesn't allow elements that have
attributes or child elements to have a value and neither JSON or Yaml allow it
either.
The only downside to this is that it will clutter up the
PropertiesConfigurationBuilder somewhat, but the whole point of the builder is
to translate the properties syntax into a Node hierarchy so it is the correct
place to perform this work.
Note that you could have created your own HadoopPropertiesConfigurationFactory
and extended the PropertiesConfigurationBuilder to do whatever you want but it
seems many of the methods in the builder class are private, making it difficult
to extend. We probably want to fix that in a separate Jira.
was (Author: ralph.go...@dslextreme.com):
The fix Matt did was to process the configuration before any other processing
was done and to replace the single property with the properties the
PropertiesConfiguration already supports. Unfortunately, that requires
resolving any variables specified in the value since the syntax of the value
covers multiple property values so you can't really know what the resolution
will be. For example
{code:java}
log4j.rootLogger=${sys:root.log.level:-INFO}, console
{code}
could be specified and then you could do -Droot.log.level="INFO, file" which,
of course, would result in
{code:java}
log4j.rootLogger=INFO, file, console
{code}
which may, or may not, have been intended. But that is the mess combining
properties this way causes, and which is why I am against using it in any other
syntax. Worse, the fix I added resolved the properties during the preprocessing
but then normal processing would have allowed a second pass at variable
resolution. So if your -D contained another ${sys:...} string it would have
been resolved, which is something we would rather avoid.
The fix I plan on doing will remove the code Matt did and simply resolve the
string as a "normal" property and perform the multiple actions that are
required at that time. This will follow normal property resolution so the
lookups will only be performed once. One other benefit is that the syntax can
be as shown above - log4j.rootLogger=. This syntax is not possible with XML,
Yaml or JSON in Log4j as our XML processing doesn't allow elements that have
attributes or child elements to have a value and neither JSON or Yaml allow it
either.
The only downside to this is that it will clutter up the
PropertiesConfigurationBuilder somewhat, but the whole point of the builder is
to translate the properties syntax into a node hierarchy so it is the correct
place to perform this work.
Note that you could have created your own HadoopPropertiesConfigurationFactory
and extended the PropertiesConfigurationBuilder to do whatever you want but it
seems many of the methods in the builder class are private, making it difficult
to extend. We probably want to fix that in a separate Jira.
> The 'rootLogger=${sys:root.logger:-INFO,console}' does not work
> ---------------------------------------------------------------
>
> Key: LOG4J2-3394
> URL: https://issues.apache.org/jira/browse/LOG4J2-3394
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
> Reporter: Duo Zhang
> Priority: Major
> Attachments: log4j2.err, log4j2.properties
>
>
> Tried the new feature introduced in LOG4J2-3341 in hbase.
> https://github.com/apache/hbase/pull/4096
> I built a tarball and try to start a standalone hbase instance locally, but
> log4j2 failed to load the system properties of rootLogger.
> Will upload the config and error output.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
