On the LowLevelLogUtil front, I’ve updated that to use StatusLogger now once StatusLogger has initialized. The code could probably be backported to 2.x.
As for how PropertiesUtil caches values, simplifications there would be great! — Matt Sicker > On Nov 6, 2022, at 03:37, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > 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
