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 "Scot Hale (JIRA)" <ji...@apache.org> on 2015/12/29 01:15:49 UTC
[jira] [Comment Edited] (LOG4J2-913) Allow to load log4j2
configuration from a centralized repository, like a database or a
webservice
[ https://issues.apache.org/jira/browse/LOG4J2-913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15073289#comment-15073289 ]
Scot Hale edited comment on LOG4J2-913 at 12/29/15 12:15 AM:
--------------------------------------------------------------
Does the logback classic include implementation solve these problems? http://logback.qos.ch/manual/configuration.html#fileInclusion
I am not sure how portable the implementation would be to log4j2 configuration. This would be a implementation that may complement or replace the xinclude. I assume you would still appreciate a patch..
was (Author: shale):
Does the logback classic include implementation solve these problems? http://logback.qos.ch/manual/configuration.html#fileInclusion
I am not sure how portable the implementation would be to log4j2 configuration. This would be a new implementation that would complement or replace the xinclude.
> Allow to load log4j2 configuration from a centralized repository, like a database or a webservice
> -------------------------------------------------------------------------------------------------
>
> Key: LOG4J2-913
> URL: https://issues.apache.org/jira/browse/LOG4J2-913
> Project: Log4j 2
> Issue Type: New Feature
> Components: Configurators
> Environment: All
> Reporter: Edwin F. López
> Priority: Critical
> Labels: configuration, database, features, webservice
>
> Hi.
> I've worked in some projects that require having a single configuration point for all my loggers since basically, all of them are web applications. Since controlling the logging event flood can be problematic when the applications are in production, it would be great if, along with the current XMLConfiguration and JSONConfiguration, there would be a configuration mechanism that could load the log4j2 from a remote location, whether it's a webservice (SOAP, ReST) or a database.
> The contract can be summarized like this:
> * Set a configuration endpoint
> * Set a polling interval
> * Allow authentication
> * Load a given named configuration
> * Reconfigure if required.
> Right now, I'm been scratching this need by code, using a ScheduledExecutorService and a pice of code like this:
> {code:java}
> LoggerContext ctx = null;
> URI uri = null;
> try {
> uri = new URI("http://localhost:7001/log4j2config/getlog4j2xmlconfig?appCode=log4jConfig§ion=full");
> } catch (URISyntaxException e) {
> System.err.println(e.getMessage());
> }
> ctx = Configurator.initialize("Log4J2Conf", Thread.currentThread().getContextClassLoader(), uri);
> ctx.start();
> {code}
> However, I believe that since this is a common scenario, it could be implemented as a new plugin.
> Thank you very much.
--
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