directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Faiz <>
Subject Re: FATAL in SLF4J, was: [VOTE] Logging Direction
Date Tue, 05 Jul 2005 04:26:13 GMT
Hi guys,
    A note to all of this.

    I sat down on the weekend to make SLF4J run. I immediately 
encountered a NoSuchMethodError via a Spring dependency, via 
commons-logging, to log4j (while I was running with nlog4j). I began 
digging around to find the missing method (a call to a log(msg, 
priority, obj, throwable) in Category, I believe) but didn't really want 
to spend my Saturday afternoon working on a transitional problem.

    I'll work on this problem and report it in more detail, later. Or 
perhaps it was a bad configuration on my part.

    This *does not* feel like the path of least resistance, however, 
towards getting something as fundamental as logging in place.


Niclas Hedhman wrote:

>On Tuesday 05 July 2005 11:18, Trustin Lee wrote:
>>Disconnection from server prevents  the application from functioning but we
>>cannot say that it is a FATAL situation because server will get up and run
>>soon possibly.  We'll have to say it is in a FATAL situation if client
>>cannot proceed the reconnect process by some reason.
>Are you talking about the exception being thrown as a result of connection 
>problems, or an exception propogated from the server to the client?
>In the first instance, it is barely an exception at all. It is a normal 
>condition and should be handled by the client very gracefully, and "at the 
>most" provide a Warning in the logs ( I would probably just put an INFO ). 
>The user will be notified of this. If a true fatal condition occurs, an Error 
>is written to the log, the user is notified with something that makes more 
>sense, and then a "Ok to Terminate" button.
>In the second instance, the client should probably not receive a "Fatal" 
>message at all. It makes users nervous to find Fatal stuff in their logs. If 
>the server enters a fatal condition, the client application should be 
>notified through a proper exception, and act gracefully to that. And no need 
>to pollute the client log with anything but the same as above, a simple 
>Sorry, but I fail to see how your use case invalidating Ceki's explanation.


Confluence - the enterprise wiki - tried it yet?

View raw message