logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Barfield (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-607) log4j2 json files do not support property substitutions
Date Thu, 31 Jul 2014 00:49:38 GMT

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

Ian Barfield commented on LOG4J2-607:

Hey, so I actually know a lot about this bug. I ran into it when implementing [a custom configuration
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
-- 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
> 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

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message