I'm not sure how much any of the devs here use the log4j-web module anymore (seems more common to use fat jars or one app per servlet container instance at least), so it's hard to say about any idiosyncrasies. The main purpose of the lifecycle hooks for web modules is to allow each class loader to have its own independent log4j config, though I'm not sure how common that deployment pattern is anymore. There are alternative strategies such as hooking into the server code itself so that logging can shutdown with the server rather than the individual applications, but that's a different use case.
As for design ideas, I think I had initially wanted to refactor the web context API to mimic how Spring Framework registers itself in the ServletContext, though I never got around to doing that, and now I typically use JVM-global logging configurations instead, so I never revisited that. On Fri, 22 Jan 2021 at 11:53, Tim Perry <[email protected]> wrote: > > Hello, > > I'd like to help fix LOG4J2-2624 and LOG4J2-1606. How can I help? > > To me, the challenge is to ensure log4j is initialized the very first time > the ServletContext is provided to any object during application loading and > startup and to stop log4j during the very last event or execution hook a > servlet 3.0 container exposes. Right now using the servlet 3.0 > auto-configuration stops log4j too soon in some cases and using the servlet > 2.5 configuration starts log4j too late in some cases. > > FWIW, I have posted a proposed fix in > https://issues.apache.org/jira/browse/LOG4J2-1606. I'm not sure if it is > the correct way to go. For one thing, it puts the Log4jWebLifeCycle > initializer into the ServletContext so that another object can grab it and > use it during log4j shutdown. Somewhere in the log4j dev archives I saw a > note about moving data out of the ServletContext so that it can't be > overwritten. I'm not sure if my solution would need to be modified or > abandoned in light of this. > > The code changes I posted are based on a custom log4j-web artifact I > created for a client. It works for them on their Tomcat 8.x servers. > However, I'm not sure if I'm relying on any idiosyncratic behaviour of > Tomcat or if there are earlier or later servlet container events / hooks > that can be used to trigger configuration to happen earlier on startup or > stop log4j later when an application is stopped. > > If I can be of any help fixing these issues, I'd like to help. > > I've gotten a lot of good use out of log4j over the years. Thank you for > maintaining it. > > Tim
