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> >