You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Trustin Lee <tr...@gmail.com> on 2005/07/05 05:18:55 UTC
Re: FATAL in SLF4J, was: [VOTE] Logging Direction
Let's assume that you've programmed a client application that always should
be connected to the server. 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.
So I think ERROR and FATAL level are both required. WARN, ERROR and FATAL
both represents exceptional situation, but three has some different meaning:
* WARN - exceptional situation, but safely ignorable because the
application can recover itself.
* ERROR - exceptional situation that requires user's attention because of
temporary malfunction of the application. The application can recover from
this situation automatically if other environment changes.
* FATAL - exceptional situation that we really didn't expected or that makes
the application stop permanently.
Trustin
2005/7/5, Ceki Gülcü <li...@qos.ch>:
>
>
> Trustin Lee wrote:
>
> > SLF4J doesn't have "FATAL" level AFAIK. Would this be OK?
>
> This question is answered in the SLF4J FAQ [1] quoted below:
>
> Why doesn't the org.slf4j.Logger interface have methods for the FATAL
> level?
>
> From the stand point of a logging system, the distinction between a
> fatal error and an error is usually not very useful. Most programmers
> exit the application when a fatal error is encountered. However, a
> logging library cannot (and should not) decide on its own to terminate
> an application. The initiative to exit the application must be left to
> the developer.
>
> Thus, the most the FATAL level can do is to highlight a given error as
> the cause for application to crash. However, errors are by definition
> exceptional events that merit attention. If a given situation causes
> errors to be logged, the causes should be attended to as soon as
> possible. However, if the "error" is actually a normal situation which
> cannot be prevented but merits being aware of, then it should be
> marked as WARN, not ERROR.
>
> Assuming the ERROR level designates exceptional situations meriting
> close attention, we are inclined to believe that the FATAL level is
> superfluous.
>
> Does this answer your question?
>
> [1] http://slf4j.org/faq.html#2.5
>
> --
>
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: FATAL in SLF4J, was: [VOTE] Logging Direction
Posted by Nick Faiz <ni...@atlassian.com>.
Ceki,
Thanks for addressing the problem so quickly.
I'll let you know how I go using it. :)
Cheers,
Nick
Ceki Gülcü wrote:
> At 07:13 AM 7/5/2005, Nick Faiz wrote:
>
>> Encouraging ... :)
>>
>> I'll take another look this evening.
>
>
> Nick, please try using NLOG4J version 1.2.14 which should solve the
> compatibility issue with Jakarta Commons Logging.
>
> As mentioned in my previous message, while printing methods in log4j
> take an argument of type java.lang.Object, the org.slf4j.Logger
> interface imposes that this parameter be of type
> java.lang.String. NLOG4J loggers which directly implement the
> org.slf4j.Logger interface relay this restriction.
>
> Luckily, JCL uses a special printing method which lies beyond those
> found in the org.slf4j.Logger interface. NLOG4J release 1.2.14
> modifies this special printing method so as to retain compatibility
> with JCL while still adhering to the org.slf4j.Logger interface.
>
>> Nick
>
>
--
ATLASSIAN - http://www.atlassian.com/
Confluence - the enterprise wiki - tried it yet?
http://www.atlassian.com/confluence/
--
Re: FATAL in SLF4J, was: [VOTE] Logging Direction
Posted by Ceki Gülcü <li...@qos.ch>.
At 07:13 AM 7/5/2005, Nick Faiz wrote:
>Encouraging ... :)
>
>I'll take another look this evening.
Nick, please try using NLOG4J version 1.2.14 which should solve the
compatibility issue with Jakarta Commons Logging.
As mentioned in my previous message, while printing methods in log4j
take an argument of type java.lang.Object, the org.slf4j.Logger
interface imposes that this parameter be of type
java.lang.String. NLOG4J loggers which directly implement the
org.slf4j.Logger interface relay this restriction.
Luckily, JCL uses a special printing method which lies beyond those
found in the org.slf4j.Logger interface. NLOG4J release 1.2.14
modifies this special printing method so as to retain compatibility
with JCL while still adhering to the org.slf4j.Logger interface.
>Nick
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
Re: FATAL in SLF4J, was: [VOTE] Logging Direction
Posted by Nick Faiz <ni...@atlassian.com>.
Encouraging ... :)
I'll take another look this evening.
Nick
Niclas Hedhman wrote:
>On Tuesday 05 July 2005 12:26, Nick Faiz wrote:
>
>
>>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).
>>
>>
>
>This could be one of the notorious JCL NoSuchMethodExceptions that you have
>encountered. The whole argument of SLF4J is exactly this ;o)
>Without a full stack trace it is hard to say.
>
>
>Cheers
>Niclas
>
>
>
--
ATLASSIAN - http://www.atlassian.com/
Confluence - the enterprise wiki - tried it yet?
http://www.atlassian.com/confluence/
--
Re: FATAL in SLF4J, was: [VOTE] Logging Direction
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 05 July 2005 12:26, Nick Faiz wrote:
> 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).
This could be one of the notorious JCL NoSuchMethodExceptions that you have
encountered. The whole argument of SLF4J is exactly this ;o)
Without a full stack trace it is hard to say.
Cheers
Niclas
Re: FATAL in SLF4J, was: [VOTE] Logging Direction
Posted by Ceki Gülcü <li...@qos.ch>.
I am afraid this one is due to a incompatibility between LOG4J and
NLOG4J/SLF4J, and not to an error in JCL. While printing methods in
LOG4J take an argument of type java.lang.Object, the org.slf4j.Logger
interface imposes that this parameter be of type
java.lang.String. NLOG4J Logger's which directly implement the
org.slf4j.Logger interface relays this restriction -- hence the
NoSuchMethodError you are observing. JCL merely reveals this
LOG4J/NLOG4J incompatibility.
What can be done? It should be fairly easy to add an NLOG4J adapter to
JCL. I'll start working on this right now and report back here and on
the dev@SLF4J.org mailing list.
Nick, it's not bad configuration on your part. I hope this incident
will not scare you off from using the SLF4J API. Perhaps you should
wait until the incident is resolved before making up your mind.
In any case, thank you for reporting this problem. Caught early, the
problem can be fixed before future users are affected.
At 06:26 AM 7/5/2005, Nick Faiz wrote:
>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.
>
>Cheers,
>Nick
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
Re: FATAL in SLF4J, was: [VOTE] Logging Direction
Posted by Nick Faiz <ni...@atlassian.com>.
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.
Cheers,
Nick
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
>Warning.
>
>
>Sorry, but I fail to see how your use case invalidating Ceki's explanation.
>
>
>Cheers
>Niclas
>
>
>
--
ATLASSIAN - http://www.atlassian.com/
Confluence - the enterprise wiki - tried it yet?
http://www.atlassian.com/confluence/
--
Re: FATAL in SLF4J, was: [VOTE] Logging Direction
Posted by Niclas Hedhman <ni...@hedhman.org>.
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
Warning.
Sorry, but I fail to see how your use case invalidating Ceki's explanation.
Cheers
Niclas