So I’m working on the properties enhancement issue, and one thing I’ve come across to clean up are the situations where the LoggerContext may be null in the constructor to AbstractConfiguration. Previously, this only seemed to be the case for NullConfiguration, but it may also apply to DefaultConfiguration during startup. However, suppose I construct a LoggerContext with a configuration location corresponding to a file (so the only supported file path type via that constructor). This location does not get used until the LoggerContext starts; before this, it constructs a DefaultConfiguration.
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’ll note for reference that LoggerContext has two families of constructors that fan out into the following parameters: String name, Object externalContext, String/URI configLocation, Injector injector, PropertyResolver propertyResolver -> LoggerContext The external context concept here seems to mainly be used for passing along a ClassLoader instance or something derived from it (I think a Bundle does or something from OSGi at least). These constructors do call Injector::init, so the point of providing an Injector instance here would be if you preconfigured some beans (like in a unit test) before wanting to load the default bundles of beans/bindings. — Matt Sicker
