[
https://issues.apache.org/jira/browse/LOG4J2-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14560691#comment-14560691
]
Jitesh Vassa commented on LOG4J2-494:
-------------------------------------
A couple of use cases that I'm interested in:
* The ability to define a common log configuration file that can be included by
applications. Where the application level configuration file can perform
overrides on things like properties and add to the filtering criteria.
* The ability to define an include as optional. This is really to serve the
use case where on a local developer workstation you might want to additionally
log to the console (eclipse), therefore having the ability to optionally source
a configuration file that lives outside the project structure would be useful.
Just a side note: when using "xinclude" you can make it optional by providing
a "fallback" block - however this results in a warning coming out of Xerces
(the DefaultErrorHandler appears to be used). It would be nice to have any
optional includes that are missing being logged at a lower level.
> 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]