[
https://issues.apache.org/jira/browse/LOG4J2-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125202#comment-14125202
]
Matt Sicker commented on LOG4J2-814:
------------------------------------
I'm somewhat experimenting a bit here, but yeah, I'm definitely not merging
this without some review. The main idea is that I'm borrowing the concept of
the Resource interface from Spring. Moving this into the plugin system can
provide simpler ways to extend the logic from ConfigurationFactory for
different configuration file loading mechanisms. The ConfigurationSource class
can be abstracted into the Resource interface.
I'll push more changes later when I've got more of this done.
> 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]
