You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Ian Barfield (JIRA)" <ji...@apache.org> on 2014/07/31 02:51:39 UTC
[jira] [Comment Edited] (LOG4J2-607) log4j2 json files do not
support property substitutions
[ 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