[
https://issues.apache.org/jira/browse/LOG4J2-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15116252#comment-15116252
]
Gary Gregory edited comment on LOG4J2-494 at 1/25/16 11:22 PM:
---------------------------------------------------------------
We should perhaps split this issue into two:
- Additive configuration: {{-Dlog4j.configuration=file1,file2,file3}} file3 is
applied on top of file 2, which was applied on top of file3.
- Log4j includes: (This is NOT XInclude) A new node that imports a
configuration into containing configuration, In XML: {{<IncludeConfiguation
uri="..." />}} with the same supported in JSON and YAML. In the included file,
overrides whatever is in the current config.
I'm not sure what the best terminology is here: "import" or "include". I'm
liking "import" better now.
was (Author: garydgregory):
We should perhaps split this issue into two:
- Additive configuration: {{-Dlog4j.configuration=file1,file2,file3}} file3 is
applied on top of file 2, which was applied on top of file3.
- Log4j includes: (This is NOT XInclude) A new node that imports a
configuration into containing configuration, In XML: {{<IncludeConfiguation
uri="..." />}} with the same supported in JSON and YAML. In the included file,
overrides whatever is in the current config.
> 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: [email protected]
For additional commands, e-mail: [email protected]