Reconfiguring already is a fast and robust operation. But if you have status=“debug” enabled it is a little disconcerting to see it configure 4 times.
Ralph > On Oct 9, 2019, at 11:49 AM, Matt Sicker <boa...@gmail.com> wrote: > > If we made reconfiguring a fast and robust operation, there’d be nothing > wrong with that approach. > > On Wed, Oct 9, 2019 at 13:41, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >> 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> >>> >> >> >> -- > Matt Sicker <boa...@gmail.com>
