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>