You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Matt Sicker (JIRA)" <ji...@apache.org> on 2014/09/06 01:24:29 UTC

[jira] [Created] (LOG4J2-814) Configuration file loading should be abstracted into a sort of ResourceLoader interface

Matt Sicker created LOG4J2-814:
----------------------------------

             Summary: 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org