[slf4j-user] Some considerations about the FATAL-level

Ceki Gulcu listid at qos.ch
Tue Oct 7 13:51:04 CEST 2008


Hello Thomas,

If the underlying implementation does not support markers, then
depending on how you look at it, the slf4j-binding will melt,
releasing cataclysmic cosmic rays resulting in a chain of events
annihilating the entire universe.


More to the point, markers are ignored if the underlying
implementation does not support them.  Thus, you can switch back to a
different logging framework at any time, even if you use markers.

HTH,



Thomas.TH.Hamacher at partner.bmw.ch wrote:
> Hi Ceki,
> 
> thank you for the details.
> So how are the Markers handled, in case I use log4j (or any other logging-framework, that does not support Markers)? Will they be handled as "normal" errors then or will it raise an error?
> Because if I introduce logback as the logging-implementation together with slf4j, it seems as if I´m stuck with that configuration then and might not be able to use a different implementation. Is that true?
> 
> Thanks
> 
> Thomas
> 
> 
> Hello Thomas,
> 
> I see. You could retain the current functionality by setting up a SMTPAppender which is triggered (i.e. sends out an email) whenever a logging event marked as FATAL occurs. You need to use SLF4J markers. Moreover, currently only logback supports markers (wheras log4j and j.u.l. do not support markers).
> 
> The usage pattern could be:
> 
>    Marker FATAL = MarkerFactory.getMarker("FATAL");
>    logger.error(FATAL, "some serious error", exception);
> 
> You can of course store FATAL as a constant somewhere in your applicaiton. The pattern then becomes
> 
>    logger.error(MyContstants.FATAL, "some serious error", exception);
> 
> I could supply the SMTPAppender configuration if you were intersted in this venue.
> 
> HTH,
> 
> 
> 
> Thomas.TH.Hamacher at partner.bmw.ch wrote:
> 
>> Hi Ceki,
>>
>> Sure! So here are some more words to clarify, what I meant!
>> Currently we defined the differences between FATAL and ERROR just in the way we handle it regarding the notification of users/developers.
>> We configured the log4j that any FATAL error should be immediately reported to the developers through an email. It does not necessarily terminate the application (because this is, what we still want to decide on our own), but we have to know about these errrors instantly!
>> ERRORs are simply logged into a log-file. So this is still an unwanted malfunction in the application (so no WARN), but does not required immediate notification and it is sufficient to see these errors in a daily scan of the log-files.
>>
>> Maybe this makes my distinction a bit clearer.
>>
>> HTH
>>
>> Thomas
>>
> --
> Ceki G?lc?
> Logback: The reliable, generic, fast and flexible logging framework for Java.
> http://logback.qos.ch
> 
> 
> ------------------------------
> 
> _______________________________________________
> user mailing list
> user at slf4j.org
> http://www.slf4j.org/mailman/listinfo/user
> 
> End of user Digest, Vol 26, Issue 4
> ***********************************
> 
> _______________________________________________
> user mailing list
> user at slf4j.org
> http://www.slf4j.org/mailman/listinfo/user

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch



More information about the slf4j-user mailing list