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

Ralph Goers edited comment on LOG4J2-913 at 4/1/19 6:21 AM:
------------------------------------------------------------

I should have provided a status update for this. I provided a patch to Spring 
Cloud Config to support If-Modified-Since which was accepted and is now in the 
latest 2.0 and 2.1 releases. I have modified Log4j's WatchManager to support 
Watching in a more general fashion. It now fully supports monitoring files 
loaded via HTTP provided the HTTP server supports If-Modified-Since. I have 
provided a Log4j-Spring-Cloud-Config module that provides a client jar to 
integrate with Spring Cloud Config and listen for changes to the backing repo 
via API and only then checking to see if the configuration was updated, thus 
eliminating the need for polling. I have created a log4j-docker module to 
retrieve information from the docker container about the running application 
and created a DockerLookup plugin. I have created a sample server and sample 
application to test all of this and to use as an example.
All of this is currently in the LOG4J2-913 branch along with updates to the web 
site.


was (Author: [email protected]):
I should have provided a status update for this. I provided a patch to Spring 
Cloud Config to support If-Modified-Since which was accepted and is now in the 
latest 2.0 and 2.1 releases. I have modified Log4j's WatchManager to support 
Watching in a more general fashion. It now fully supports monitoring files 
loaded via HTTP provided the HTTP server supports If-Modified-Since. I have 
provided a Log4j-Spring-Cloud-Config module that provides a client jar to 
integrate with Spring Cloud Config and listen for changes to the backing repo 
via API and only then checking to see if the configuration was updated, thus 
eliminating the need for polling. I have created a log4j-docker module to 
retrieve information from the docker container about the running application 
and created a DockerLookup plugin. I have created a sample server and sample 
application to test all of this and to use as an example.

> 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
>            Assignee: Ralph Goers
>            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&section=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
(v7.6.3#76005)

Reply via email to