[jira] [Created] (LOG4J2-494) Support composite configurations

[Ralph Goers (JIRA)]

Ralph Goers created LOG4J2-494:
----------------------------------

Summary: 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


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.1.5#6160)

[Ralph Goers (JIRA)]

[ https://issues.apache.org/jira/browse/LOG4J2-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralph Goers reassigned LOG4J2-494:
----------------------------------

Assignee: Ralph Goers

Post by Ralph Goers (JIRA)
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.1.5#6160)

[Hiten Patel (JIRA)]

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

Hiten Patel commented on LOG4J2-494:
------------------------------------

As mentioned in the last comment of this ticket - https://issues.apache.org/jira/browse/LOG4J2-804, it would be more useful to support similar File Inclusion mechanism supported by logback. Linking a similar question asked in Stackoverflow here - http://stackoverflow.com/questions/25694782/log4j2-file-inclusion-include-and-included-similar-to-logback

Post by Ralph Goers (JIRA)
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)

[Hiten Patel (JIRA)]

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

Hiten Patel edited comment on LOG4J2-494 at 9/9/14 12:54 AM:
-------------------------------------------------------------

It would be more useful to support File Inclusion mechanism similar to what is being supported by logback today. Linking a similar question asked in Stackoverflow here - http://stackoverflow.com/questions/25694782/log4j2-file-inclusion-include-and-included-similar-to-logback



was (Author: echelon_apache):
As mentioned in the last comment of this ticket - https://issues.apache.org/jira/browse/LOG4J2-804, it would be more useful to support similar File Inclusion mechanism supported by logback. Linking a similar question asked in Stackoverflow here - http://stackoverflow.com/questions/25694782/log4j2-file-inclusion-include-and-included-similar-to-logback

Post by Ralph Goers (JIRA)
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)