log4s: Changes of ini parameters an saving an image

[jtu...@objektfabrik.de]

Hi

I am playing with log4s again, and it seems I've found a bug.

What happened:
I played a bit with ini settings and a development image. After some changing values, I saved my image and started it anew.
One of the changes made to the .ini was the name of the daily rolling log file.

After restarting the image log4s still appended to the old file instead of creating a new one with the new name from the ini file. So it seems that the saved singleton instance was still alive and happily doings its job, using the settings it was saved with instead of the changed settings from the ini file.

Not knowing if this is expected behaviour, I'll try and tell you what MY expectation was:
If I start an image that was saved with a running logger and its appenders, it should always respect what's in my ini file. So it should either throw away its instance on quitting an image or on starting it and finding some ini entries in the log4s stanza.

I know you could argue that this is only relevant in a development image, because you usually don't save production images. I'd partly agree, but the risk here is that a production image gets packaged out of an image that had a running logger (maybe the one used during a hudson-initiated automated build job as we use it on our projects). So the production image ends up with a logger configuration that is completely screwed in production.

So there is two possibilities one could solve this:
a) projects are told to start their logging by hand, making sure whatever is present in the image when an application starts is either thrown away or at least checked for its corectness.
b) the code does it automatically

I haven't checked if this only happens if nothing else than the rolling file name is changed, so maybe this is really a very special tiny problem in some corner ;-)

Joachim

[jtu...@objektfabrik.de]

A few more thoughts on log4s can be found here: http://joachimtuchel.wordpress.com/2012/03/02/things-they-never-told-you-about-log4s/

[Donald MacQueen]

Joachim,

You are correct . The log4s shutDown method only closes open appenders; it does not clear out the log4s objects created and held by EsLogManager.
I will speak to the person responsible for this oversight. ;-)

Thanks

Donald [|]

[Donald MacQueen]

Joachim,

You are right about the documentation.

2) The way to see the output on TranscriptTTY is to run the image with the -lCON option. That's lower case l followed by CON for console, or you can specify a log file name.

Thanks again.

Donald [|]

[Donald MacQueen]

Joachim,

add this line to EsLogManager>>shutDown:

  self removeAllLoggers

On Friday, March 2, 2012 5:41:07 AM UTC-5, jtu...@objektfabrik.de wrote:

[Donald MacQueen]

Actually the documentation has this to say under the heading Initializing the log4s Framework

o        A non-empty stanza must have the following three lines (shown here with the recommended values.)

debugEnabled=true

quietMode=false

globalLevel=All

[jtu...@objektfabrik.de]

Donald,

I have to apologize. It is in the docs, in the VA Smalltalk User's Guide, Chapter log4s, section "Initializing the log4s Framework". 

Sorry.  I don't know why I didn't see it. It's actually not written in any secret ink or anything...

Joachim

[jtu...@objektfabrik.de]

Don,

thanks, I'll try it and let you know if that solves my problems. I see no reason why it shouldn't.

Joachim