I am not really sure what the question here is. When you pass in a configuration location you are going to end up with a LoggerContext that references a Configuration derived from the information at that location. Yes, it may create a DefaultConfiguration along the way but that is primarily because logging may need to occur while Log4j is configuring.
As for the external context, that was initially created to support binding with things like Spring. However, the way Spring Boot ended up using it caused some issues for adding extended Spring support so the LoggerContext now contains a Map so that multiple “external” values can be captured. The ExternalContext is just stored in a specific key. Given how the injector worked the last time I looked at it I don’t really see how Spring could use it. Ralph > On Dec 18, 2022, at 12:29 PM, Matt Sicker <m...@musigma.org> wrote: > > 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 >
