There was a copy and paste user error in the ERROR description. It should read:
ERROR, use the ERROR level priority for events that indicate a disruption in a request or the ability to service a request. A service should have some capacity to continue to service requests in the presence of ERRORs. ----- Original Message ----- From: "Scott M Stark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 15, 2001 1:59 PM Subject: [JBoss-dev] org.jboss.logging.Logger priority usage recommendations > These are the log4j priority usage recommendations that I intend on > introducing into Main next week. Reply with any critque or questions. > > TRACE, use TRACE the level priority for log messages that are directly > associated with activity that corresponds requests. Further, such > messages should not be submitted to a Logger unless the Logger category > priority threshold indicates that the message will be rendered. Use the > Logger.isTraceEnabled() method to determine if the category priority > threshold is enabled. The point of the TRACE priority is to allow for > deep probing of the JBoss server behavior when necessary. When the > TRACE level priority is enabled, you can expect the number of messages > in the JBoss server log to grow at least a x N, where N is the number of > requests received by the server, a some constant. The server log may > well grow as power of N depending on the request-handling layer being > traced. > > DEBUG, use the DEBUG level priority for log messages that convey extra > information regarding life-cycle events. Developer or in depth information > required for support is the basis for this priority. The important point > is that when the DEBUG level priority is enabled, the JBoss server log > should not grow proportionally with the number of server requests. > Looking at the DEBUG and INFO messages for a given service category > should tell you exactly what state the service is in, as well as what > server resources it is using: ports, interfaces, log files, etc. > > INFO, use the INFO level priority for service life-cycle events and other > crucial related information. Looking at the INFO messages for a given > service category should tell you exactly what state the service is in. > > WARN, use the WARN level priority for events that may indicate a > non-critical service error. Resumable errors, or minor breaches in request > expectations fall into this category. The distinction between WARN and > ERROR may be hard to discern and so its up to the developer to judge. > The simplest criterion is would this failure result in a user support > call. If it would use ERROR. If it would not use WARN. > > ERROR, use the ERROR level priority for events that indicate > non-critical errors that do represent a disruption in a request or the > ability to service a request. A service should have some capacity to > continue to service requests in the presence of ERRORs. > > FATAL, use the FATAL level priority for events that indicate a critical > service failure. If a service issues a FATAL error it is completely > unable to service requests of any kind. > > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
