Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Date: Mon, 25 Jan 2016 12:23:40 +0000 (UTC)
From: "Philipp Knobel (JIRA)" <jira@apache.org>
To: log4j-dev@logging.apache.org
Message-ID: <JIRA.12688406.1389466957000.199627.1453724620047@Atlassian.JIRA>
In-Reply-To: <JIRA.12688406.1389466957000@Atlassian.JIRA>
References: <JIRA.12688406.1389466957000@Atlassian.JIRA>
 <JIRA.12688406.1389466957830@arcas>
Subject: [jira] [Commented] (LOG4J2-494) Support composite configurations
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Philipp Knobel commented on LOG4J2-494:
---------------------------------------

I think before it actually makes sense to start working on this issue, the basic scope/path to go needs to be defined.
Right now I basically see two possible approaches available:

1. Composite configurations, on startup you simply specifiy multiple configurations, which are merged into one. The later configuration wins over stuff defined in previous configurations. With this, you basically could override anything with your app specific configs.
2. Extend xinclude, currently xinclude seems to be capable of only including the full file and there's no proper notion of optional. It seems that extending xinclude to properly support xpointers could solve the required functionality already. This would allow to have multiple configurations, where each config file would be a valid log4j2 configuration. The xinclude would then just pull in parts of the file (like appenders), the resulting configuration (in memory) would be basically the same as with option 1.

To me it looks like, we're close to what is needed for composite log configuration, with the help of xinclude. But I lack the knowledge to say if this would be the way to go and this would be limited to xml based configuration only. On the other side, option 1 actually seems to be more general being applicable to all kinds of configurations as this would work on the java structure rather than some specific configuration file. One probably could even mix multiple file formats. Log4j2 could automatically use this approach if it detects multiple configurations. So it seems that option 1 should be the preferred way.

> Support composite configurations
> --------------------------------
>
>                 Key: LOG4J2-494
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-494
>             Project: Log4j 2
>          Issue Type: New Feature
>          Components: Configurators
>    Affects Versions: 2.0-beta9
>            Reporter: Ralph Goers
>            Assignee: Ralph Goers
>
> Support was added to XMLConfiguration to allow XIncludes in the XML files. While this can be useful it does not allow for the use case where someone wants a default configuration and then a custom configuration to be merged with it.
> I am proposing creating a CompositeConfiguration class that accepts a comma separated list of configuration files. It would then use the Configuration factories to create the appropriate Configuration classes for each of the underlying files.  It would then merge the Node hierarchies created by each into a single tree and then finally construct the actual configuration Objects from that tree.
> There are a few issues with this - for example each configuration can specify debug and verbose attributes, duplicate property settings, handling duplicate Appender names, etc.  Most of these should be fairly easy to resolve.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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