It’s NullConfiguration that’s the overly-expensive null guard for preventing operations from blowing things up during shutdown. There’s a small period of time between the stopping of Log4j and the stopping of the JVM that other code could still be trying to send new log messages, so they need to go be processed by something basically. I’ve been working on a rewrite of NullConfiguration to be much lighter, but it would be fairly difficult to remove entirely without affecting log messages at shutdown. — Matt Sicker
> On Dec 28, 2022, at 14:02, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi Ralph > > On Wed, 28 Dec 2022 at 18:38, Ralph Goers <ralph.go...@dslextreme.com> wrote: >>> On Dec 28, 2022, at 7:01 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> >>> wrote: >>> I think we should rely more on our `LifeCycle` abstraction: >>> `Configuration` starts in the "initializing" state and does not have >>> any subcomponents (especially those that require a `LoggerContext` to >>> be present) until `initialize()` is called. >> >> Actually, a LoggerContext is hard-wired with a DefaultConfiguration. So as >> soon as it exists it has a Configuration. Once the Configuration identified >> from the configLocation is created the DefaultConfiguration is replaced. >> This is the discussion Matt was having in his previous email and didn’t >> understand why it is required to work that way. Note that once the >> LoggerContext is constructed it will be “wired” by the ContextSelector and >> will be usable by any thread. > > I was aware of that, but I always thought of the DefaultConfiguration > as an overly-expensive null checkguard. > >>> Logging does not occur until `start()` is called. >> >> I don’t believe this is true. Once the ContextSelector registers it any >> calls to log will use it. > > You are right: the DefaultConfiguration is ready to log as soon as the > LoggerContext constructor exits. Thank you for the clarification. > > Piotr
