[ https://issues.apache.org/jira/browse/LOG4J2-814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Sicker closed LOG4J2-814. ------------------------------ Resolution: Duplicate Turns out that ConfigurationSource is basically the same thing. > Configuration file loading should be abstracted into a sort of ResourceLoader > interface > --------------------------------------------------------------------------------------- > > Key: LOG4J2-814 > URL: https://issues.apache.org/jira/browse/LOG4J2-814 > Project: Log4j 2 > Issue Type: Improvement > Components: Core > Reporter: Matt Sicker > > The main bit of code to look at here is in > {{ConfigurationFactory.getInputFromUri(URI)}}, which returns a > ConfigurationSource. Now, sure, a user can override the default > ConfigurationFactory class and override that method. However, I think it may > be more beneficial to use a sort of resource loader plugin architecture > similar to > [Spring|http://docs.spring.io/spring/docs/current/spring-framework-reference/html/resources.html] > for the same reasons specified by Spring. These could be standard Log4j > plugins which would be mapped to URI schemes, and we'd have a few > implementations as well. > Ideally, we should be able to use URI (or some abstracted class like > Resource) everywhere to specify a configuration file location so that this > architecture could be used generically. Plus, going this route would be more > Log4j-like than specifying a system property and globally overriding the > ConfigurationFactory. > Config file change monitoring would be a good thing to keep in mind for any > implementation of this idea. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org