[ 
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

Reply via email to