[prev in list] [next in list] [prev in thread] [next in thread]
List: log4j-dev
Subject: [jira] [Comment Edited] (LOG4J2-607) log4j2 json files do not support property substitutions
From: "Ian Barfield (JIRA)" <jira () apache ! org>
Date: 2014-07-31 0:51:39
Message-ID: JIRA.12708912.1397682572126.82675.1406767899351 () arcas
[Download RAW message or body]
[ https://issues.apache.org/jira/browse/LOG4J2-607?page=com.atlassian.jira.plugin. \
system.issuetabpanels:comment-tabpanel&focusedCommentId=14080319#comment-14080319 ]
Ian Barfield edited comment on LOG4J2-607 at 7/31/14 12:51 AM:
---------------------------------------------------------------
Hey, so I actually know a lot about this bug. I ran into it when implementing [a \
custom configuration \
factory|https://github.com/addthis/hydra/commit/809d0d92ce3799eb043b33f7198bea9a77cfa61e] \
that supports [hocon|https://github.com/typesafehub/config/blob/master/HOCON.md].
Firstly -- Silviu, your problem is indeed disjoint from the original one, and your \
assessment is more or less correct. I would say that a map *is* appropriate but that \
the keys should be the property names rather than the word 'property' over and over \
again. The JSON syntax seems to suffer quite a lot from being a second class citizen.
With that out of the way, the titular bug is something of a misnomer. It is perhaps \
more accurately split into these theoretical sub-issues:
- (feature request) It seems ridiculous and unnecessary to require that "Properties \
declaration must be the first element in the configuration" (see \
AbstractConfiguration:345). More generally, I would discourage any assumptions \
whatsoever about the order JSON object keys are defined in. I can't comment on \
whether it makes any sense for the XML form.
- (documentation request) That seems like a pretty important rule, but I failed to \
find any mention of it in the documentation materials.
- (bug report) The logic that is supposed to warn users that a configuration has \
violated this rule is broken. Instead it silently ignores the 'properties' section. \
It seems to have been broken ever since \
https://issues.apache.org/jira/browse/LOG4J2-398. I suggest maybe \
either:
-- checking for the existence of any 'properties' key up front (also resolves the \
above feature request)
-- replacing the roundabout 'tempLookup' field + associated logic with as many \
helpfully named booleans as your heart may desire. You can fit four booleans in the \
memory spent on that otherwise useless object reference, but you probably only need \
one.. and it can be local to the method.
tl;dr - move {{,"ThresholdFilter": \{ "level": "all" \}}} to the line after you \
define your properties and it will work again.
was (Author: ianbarfield):
Hey, so I actually know a lot about this bug. I ran into it when implementing [a \
custom configuration \
factory|https://github.com/addthis/hydra/commit/809d0d92ce3799eb043b33f7198bea9a77cfa61e] \
that supports [hocon|https://github.com/typesafehub/config/blob/master/HOCON.md].
Firstly -- Silviu, your problem is indeed disjoint from the original one, and your \
assessment is more or less correct. I would say that a map *is* appropriate but that \
the keys should be the property names rather than the word 'property' over and over \
again. The JSON syntax seems to suffer quite a lot from being a second class citizen.
With that out of the way, the titular bug is something of a misnomer. It is perhaps \
more accurately split into these theoretical sub-issues:
- (feature request) It seems ridiculous and unnecessary to require that "Properties \
declaration must be the first element in the configuration" (see \
AbstractConfiguration:345). More generally, I would discourage any assumptions \
whatsoever about the order JSON object keys are defined in. I can't comment on \
whether it makes any sense for the XML form.
- (documentation request) That seems like a pretty important rule, but I failed to \
find any mention of it in the documentation materials.
- (bug report) The logic that is supposed to warn users that a configuration has \
violated this rule is broken. Instead it silently ignores the 'properties' section. \
It seems to have been broken ever since \
https://issues.apache.org/jira/browse/LOG4J2-398. I suggest maybe \
either:
-- checking for the existence of any 'properties' key up front (also resolves the \
above feature request)
-- replacing the roundabout 'tempLookup' field + associated logic with as many \
helpfully named booleans as your heart may desire. You can fit four booleans in the \
memory spent on that otherwise useless object reference, but you probably only need \
one.. and it can be local to the method.
tl;dr - move {code},"ThresholdFilter": { "level": "all" }{code} to the line after you \
define your properties and it will work again.
> log4j2 json files do not support property substitutions
> -------------------------------------------------------
>
> Key: LOG4J2-607
> URL: https://issues.apache.org/jira/browse/LOG4J2-607
> Project: Log4j 2
> Issue Type: Bug
> Affects Versions: 2.0-rc1, 2.0-rc2
> Environment: Windows 7, JVM 7, Tomcat 7. Also tested using Mac OS X and JVM 8 \
> (Tomcat 7).
> Reporter: Sebastian Audet
> Attachments: log4j2.json
>
>
> Using Property substitution in the latest release candidate doesn't work in JSON \
> configuration files. Seems to work fine in XML files though - suggest actually \
> parsing the results of the JSON file configurations?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic