Ralph
> On Dec 28, 2022, at 7:01 AM, 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.
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.
>
> We can do the same thing with `LoggerContext`: after the constructor
> exits it does not have a configuration and is in the "initializing"
> state.
After the Constructor exists is has a DefaultConfiguration.
> 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.
I don’t believe this is true. Once the ContextSelector registers it any calls
to log will use it.
Ralph
