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

["Matt Sicker (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125099#comment-14125099 ] 

Matt Sicker commented on LOG4J2-814:
------------------------------------

I think this might be able to replace the existing ResourceLoader stuff I added a while back for OSGi support (especially since I figured out how to use a Bundle ClassLoader as demonstrated in log4j-api). As part of this work, I think adding an {{spi}} package in log4j-core is in order. Possibly move some classes there as well such as ShutdownRegistrationStrategy, Clock (though it might be too late?), SecretKeyProvider (ditto), LogEventFactory (not really sure what it's doing in {{impl}}), and ResourceLoader (new version).

> 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