Hi Matt, On Sat, 5 Nov 2022 at 22:32, Matt Sicker <m...@musigma.org> wrote: > After an attempt at soloing the idea, I’ve reverted my changes and am instead > documenting the current system along with adding some proposals in the > following Confluence doc [0]. I’ve analyzed the initialization ordering of > the API (without going into detail of how log4j-core initializes as this > differs fairly significantly in 2.x and 3.x at this point). Right now, some > of the main differences between 2.x and master is that most of the documented > static fields from initialization are currently refactored into Lazy<T> > static fields, though that only defers initialization until slightly later.
Thanks for analyzing and writing down this quite complex initialization process. My main concerns with the way this works now are: 1. Logging of errors in the pre-StatusLogger phase is inconsistent. Some classes use `LowLevelLogUtil`, some ignore errors, while the usage of StatusLogger I introduced in `ServiceLoaderUtil` is brittle: it requires to call `loadServices` with `verbose = false` to disable the usage of `StatusLogger`. I think that the ideal solution would be to remove enough static initialization from `StatusLogger` and `AbstractLogger` (i.e. move it to constructors) so that LowLevelLogUtil can create a `StatusLogger` with a hardcoded configuration. Later in the initialization process we can replace it with the real `StatusLogger`. 2. There are still a couple of singleton classes that cache the result of `PropertiesUtil.getProperty` in private static fields. I think these calls can be easily moved to the constructor of the class. E.g. `StatusLogger` could easily have a constructor that does not require `PropertiesUtil` at all. 3. The way `PropertiesUtil` caches values could be simplified (cf. discussion in https://issues.apache.org/jira/browse/LOG4J2-3621): it caches all values from environment variables and Java system properties at startup. Most of the time none of those values configure Log4j2. On the other hand missing values are not cached, so most of the time a lookup for `log4j2.configurationFile` will find no value in the cache, perform a lookup in all available property sources and return `null`. Most of these changes can also be done in `release-2.x` without breaking public and protected members. Piotr
