I am sure we could, but I am not sure how that helps the usage in Spring. 

Another thought would be to have Log4j reconfigure when it finally has access 
to a configuration in the application.yaml, but that would mean configuring 
Log4j a 4th time.

Ralph

> On Oct 9, 2019, at 11:12 AM, Matt Sicker <boa...@gmail.com> wrote:
> 
> Can we provide a log4j configuration facade API for doing common
> programmatic configuration tasks like that? Think Configurator but for
> manipulating certain aspects of a Configuration that's already
> running.
> 
> On Wed, 9 Oct 2019 at 12:49, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>> 
>> Recently I added support for Spring Cloud Config to Log4j.  In an effort to 
>> continue to persuade Spring to use Log4j as the default Logging 
>> implementation I would like to consider other ways we could improve our 
>> Spring integration. The problem is, I am not really sure what that would be.
>> 
>> Currently, Spring uses a lowest common denominator approach in that you can 
>> configure root logging levels in application.yaml but it doesn’t support 
>> declaring appenders or filters. I’ve thought about being able to add the 
>> log4j logging configuration to the application.yaml, but Spring Boot 
>> actually initializes logging 3 times - once in SpringApplication.java where 
>> it has an SLF4J logger declared, again in Spring’s “boot” logger, and lastly 
>> when it initializes logging for the application. I am pretty sure only this 
>> last one would have any hope of being able to use the application.yaml and 
>> even then I am not sure if the logging configuration happens before it is 
>> available to be accessed.  I also thought about creating a Spring Lookup to 
>> be able to access Spring properties, but again if Log4j initializes before 
>> Spring the variables would not be available.
>> 
>> Thoughts or ideas?
>> 
>> Ralph
> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com>
> 


Reply via email to