I rewrote this to shut down listeners based on the contextName. In testing, I discovered that the StatusConsoleListener is created in StatusConfiguration, but neither StatusConfiguration nor StatusConsoleListener receive events to indicate when they should stop.
It appears that only one StatusConsoleListener object is ever created and it is never shut down. Looking at the api XmlConfiguration, it calls StatusConfiguration.initilize() which then either changes the log level to match the config being parsed or creates a new StatusLogger directed to the file indicated in the XML configuration. Unless I'm reading the code wrong, this means that the status logger output location depends on if a previous app was loaded. If so, then that location will continue to receive StatusLogger messages but at the log level of the new application's config. Am I reading this correctly? If I am, is this the intended behaviour? On Wed, Feb 24, 2021 at 8:29 AM Matt Sicker <boa...@gmail.com> wrote: > The StatusLogger has various listeners attached. I think adding and > removing listeners on startup and shutdown of a LoggerContext might be > a potential way to do this? > > On Wed, 24 Feb 2021 at 01:07, Tim Perry <tim.v...@gmail.com> wrote: > > > > Ralph, > > > > Thanks for the review. Yep, that *is* a problem...I knew it was a > singleton > > but didn't think through the use case you describe. This is ironic since > a > > few months ago I recommended that one of my clients bundle log4j in each > > war rather than on Tomcat's classpath so there would be less chance of > > instances walking on each other. Sigh. > > > > > > What is the correct behaviour if: > > > > - log4j is on Tomcat's classpath > > - App A has status_A.log > > - App B has status_B.log > > > > Now assume both apps are started. At this point I assume we should be > > writing to both status_A.log and status_B.log. Now we stop App B. I > assume > > we should stop writing to status_B.log but not status_A.log. Further, I > > assume that if both apps are unloaded from Tomcat, but Tomcat is left > > running, then the status logger should send its messages to standard out. > > If my assumptions are correct, then maybe we need to keep track of what > > file, if any, each web app requested messages to be written to. On top of > > that, I think we need a Callback in Log4j's shutdown registry and we need > > to run it last. > > > > > > In some ways this seems like an XY problem. Is the correct question how > do > > we reconfigure the logging when a web app shuts down? Or should it be: > > should the StatusLogger be shared across multiple LoggerContexts? > > > > > > This will be more interesting than I first realized! > > > > Tim > > > > > > On Tue, Feb 23, 2021 at 10:38 PM Ralph Goers <ralph.go...@dslextreme.com > > > > wrote: > > > > > Yeah, I started a review but then I thought it probably would be > better to > > > respond here. > > > > > > You are on the right track but there is a problem. StatusLogger is a > > > singleton - there is one instance anchored in a static. You are > invoking > > > the shutdown logic from the shutdown of the LoggerContext which is not > a > > > singleton. Log4j supports multiple LoggerContexts in an application. > For > > > example, if you are old school and running multiple web applications in > > > Tomcat and have Log4j on Tomcat’s class path then you will have > multiple > > > LoggerContexts with a single StatusLogger. So if one web app gets > > > redeployed then its LoggerContext will be shutdown and a new one > created > > > all while another app is continuing to run. > > > > > > If you’ll notice the StatusConfiguration class in log4j-core tries to > > > accommodate for this during startup, but it doesn’t do anything at > > > shutdown. StatusLogger currently isn’t smart enough to handle one app > > > writing to one destination and a different on writing to a different > one. > > > Since StatusLogger is a singleton it can’t really know which app a > status > > > log event is for. > > > > > > There are a couple of ways I can think of to handle this but none of > them > > > is perfect. > > > Modify StatusConfiguration to keep track of what each > StatusConfiguration > > > set up and reset to whatever the prior StatusConfiguration had. The > problem > > > with this is that applications might shutdown in a different order than > > > they were started, so figuring out what the prior configuration was > could > > > be difficult. > > > Add the call to prepareToStop() as a new Callback to Log4j’s shutdown > > > registry. However, this callback would need to run last. The shutdown > > > registry currently doesn’t support a way to specify the order of > callbacks. > > > Support for that would need to be added for this to work. > > > > > > Ralph > > > > > > > On Feb 23, 2021, at 10:48 PM, Tim Perry <tim.v...@gmail.com> wrote: > > > > > > > > Ralph, > > > > > > > > I implemented what you suggested. Feel free to suggest improvements. > > > > https://github.com/apache/logging-log4j2/pull/469 > > > > > > > > Tim > > > > > > > > On Tue, Feb 23, 2021 at 2:14 PM Ralph Goers < > ralph.go...@dslextreme.com> > > > > wrote: > > > > > > > >> I would suggest that if it is writing to something other than > System.out > > > >> that it be redirected back there and then the OutputStream be > closed. > > > >> However, I’ve not looked at the code recently so I am not sure what > it > > > >> takes to do that. > > > >> > > > >> Ralph > > > >> > > > >>> On Feb 23, 2021, at 2:22 PM, Tim Perry <tim.v...@gmail.com> wrote: > > > >>> > > > >>> Thank you, Volkan. > > > >>> > > > >>> I'm not quite ready to submit a PR. I was hoping some of you with > more > > > >>> knowledge of log4j-core would weigh in on what we should do about > > > >> shutting > > > >>> down the StatusLogger. > > > >>> > > > >>> My thought is we choose one of two options: > > > >>> > > > >>> Option A: > > > >>> 1) check if any StatusLogger is writing to standard out or standard > > > >> error. > > > >>> If not, add one. > > > >>> 2) stop any loggers that don't write to standard out or standard > error. > > > >>> > > > >>> Option B: > > > >>> 1) stop any loggers that don't write to standard out or standard > error. > > > >>> > > > >>> Option A could cause the log messages to be split across two > > > >> destinations, > > > >>> but they all get sent somewhere. Option B could lose shutdown > messages > > > >> when > > > >>> writing to a file, but by that point it may not matter. > > > >>> > > > >>> If any of you have a better idea, I'm happy to implement it. If > nobody > > > >>> weighs in on the best option, I'll probably submit Option A as a > pull > > > >>> request on Friday or Saturday. > > > >>> > > > >>> Tim > > > >>> > > > >> > > > >> > > > >> > > > > > > >
