log4s: Changes of ini parameters an saving an image

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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/l7hWfo-3v8YJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

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

Am Freitag, 2. März 2012 11:41:07 UTC+1 schrieb [hidden email]:

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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/392_lVKCYO0J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

On Friday, March 2, 2012 5:41:07 AM UTC-5, [hidden email] wrote:

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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/ys3R6J0E8zUJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

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 [|]

On Friday, March 2, 2012 7:05:03 AM UTC-5, [hidden email] wrote:

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

Am Freitag, 2. März 2012 11:41:07 UTC+1 schrieb [hidden email]:

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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/1WroLEBnIgwJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Joachim,

add this line to EsLogManager>>shutDown:

  self removeAllLoggers

On Friday, March 2, 2012 5:41:07 AM UTC-5, [hidden email] wrote:

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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/SvcAI73GuQwJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

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

On Friday, March 2, 2012 7:24:35 PM UTC-5, Donald MacQueen wrote:

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 [|]

On Friday, March 2, 2012 7:05:03 AM UTC-5, [hidden email] wrote:

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

Am Freitag, 2. März 2012 11:41:07 UTC+1 schrieb [hidden email]:

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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/5c1oogzDIPYJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Donald,

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/JCr8me4rueQJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Don,

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/X0GUlCThobQJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.