[ 
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]

Reply via email to