Re: Logging problem

Just to follow up on my own post, I've found a simple way to cause that
closing tag to be written to the log file. My program is launched for a
very simple JFrame that has two buttons, one for each of the two
principal classes. I've added code so that when I click on the close
button on the JFrame, I simply use the Logger object to determine all the
handlers for that Logger. Then, I do a for each loop to go through the
handlers and simply close each one. Upon completion, my physical log file
has no lock file associated with it and I can open it without difficulty.
When I edit the log file, I see that the</log> tag is right where it
should be.

It's a bit of a sledgehammer approach to the problem but I can fine-tune
it to close only the FileHandler. But it doesn't answer the question of
how the situation would be handled in the real world. Are real production
programs closing physical log files when they stop running? It seems
unlikely that a 24x7 (or nearly 24x7) application would stop running at
all except for a maintenance period yet if it starts writing error
messages to its log, I can't see people waiting until the log is full
before they get their hands on it and find out what's going on.

It would be very helpful if someone could explain what would happen in a
real-world production situation where a long-running batch program or a
constantly-running online program started writing error messages to the
log. What will operators do to be able to read the log? I'm guessing they
force it to close early and then start a new file or they have a tool
that will read the log file correctly even without the final</log> tag.