I don’t really have much to say about the confluence page. It is simply documenting how things work. I should add that I believe the static block in LogManager has been there since the very first commit. However, things have gotten much more complicated, especially due to the addition of the garbage free code.
I don’t have any real issues with what you are proposing in the second paragraph. My feeling is that log4j-api should not contain any code that can only be used by log4j modules. Everything in it should be primarily targeted at users or things that can be used by any implementation of the API. As for log4j-spi, we would have to discuss what the purpose of that is. If it is stuff that is available to any logging implementation that would be good from the standpoint of making it obvious that it isn’t for end-user consumption. But we already have an spi package in log4j-api so I wonder if that is actually necessary. We just haven’t done a very good job of putting packages and classes under the spi package. I think any classes that are designed to only be used by the log4j implementation belong in log4j-core. But even there we need to do a better job of identifying what is available to users and what is internal to log4j. So the devil is in the details. I don’t think you can just make a general proposal without discussing at least some of the classes involved and what you are trying to achieve with them. Ralph > On Nov 5, 2022, at 2:32 PM, 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. > > I’d like to work on a proper SPI here so that I can get back to considering > updates to log4j-core and dependency injection. In general, my idea is to add > a getInstance(Class<T>) method to the API provider class which would be used > to get the LoggerContextFactory along with initial instances for > ThreadContextMap and ThreadContextFactory. This could become a natural place > to also return a PropertyEnvironment instance (the interface that > PropertiesUtil now implements) to further avoid use of static state. > > Let me know what you think of the idea. Do we need a separate log4j-spi > module? Other ideas? > > [0]: https://cwiki.apache.org/confluence/display/LOGGING/API+Initialization > — > Matt Sicker >
