Using LifeCycle more would be neat, though its semantics aren’t well defined. In the Injector API, any no-arg method annotated with @Inject is considered equivalent to a @PostConstruct-style method which is similar to `LifeCycle::initialize`. The start() and stop() methods are more domain-specific so far, and any attempt at automating lifecycles along those would be somewhat complex without a complete understanding of the lifecycle of various subsystems. Generally speaking, the plugin and DI system have worked fairly well so far with allowing concepts to remain extremely modular such that working on, say, the rolling appender, has nothing to do with working on async logging or pattern conversion or lookups or anything else. LifeCycle is used ad hoc by many of these very independent concepts which would require a more detailed understanding of everything.
So, uh, maybe one day! — Matt Sicker > On Dec 28, 2022, at 08:01, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi Matt, > > On Sun, 18 Dec 2022 at 20:30, Matt Sicker <m...@musigma.org> wrote: >> During this bootstrapping, if the configuration location is available (such >> as for a unit test), should LoggerContext set up the configuration provided? >> Or is there some sort of cyclic dependency here preventing us from loading >> ConfigurationFactory right away? So far, the only cyclic dependencies I’ve >> found are related to plugins created in the DefaultConfiguration (or the >> NullConfiguration in some cases), but those are already commented as such >> (like in PatternLayout). > > 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. > > We can do the same thing with `LoggerContext`: after the constructor > exits it does not have a configuration and is in the "initializing" > state. The configuration will be created on an `initialize()` call > (maybe chained from `start()`). By then we can safely pass a reference > to `LoggerContext` to the `AbstractConfiguration` constructor. > > Logging does not occur until `start()` is called. > > Piotr
