[
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: [email protected]
For additional commands, e-mail: [email protected]
