Excellent...
Bradley Ward-3 wrote: > > The main thing that I see in your log file is that you are logging what > are very low level events within your application (entering a screen, > leaving a screen) at the INFO level. I seriously doubt you will want to > see low level events like that ALL the time for EVERY user once your > application is in production use. Most of your log statements look to be > to be more appropriate for DEBUG messages, not INFO messages. > > I work with both Java and .Net, and I use log4j in the Java applications > and log4net in the .Net applications. Four or five years ago I wrote some > general usage instructions for using logging. I originally wrote it for > Java developers, then later quickly adapted it for log4net users, so you > will see a mix of those references in the text. Also, my own usage of > log4net has evolved some since I wrote this document. > > But I will include the text from this document below in hopes you can find > something useful in it... > > Brad > > > Logging Recommendations > > A production quality software system must perform all required business > related functionality in a dependable and responsive manner. But it must > also be constructed in such a way that when problems do occur (and they > will), the problems can be quickly diagnosed on the production system > while minimizing the disruption of service via any “bouncing” of the > application server. > > The open source log4j logging package is by far the most widely used > logging system for production systems written on the Java platform. Log4j > is an excellent choice because it is very flexible, highly efficient, and > widely understood by most Java developers. But there are number of > requirements that Log4j does not directly address “out of the box”, and > there are other benefits that can be obtained from Log4j if it is properly > designed and used in the production application. > > Missing “Out of the Box” Features > > Automatic Re-Configuration at Runtime > > During development time, any class or method of any complexity should > include debug level messages wrapped within “if (log.isDebugEnabled())” > blocks of code. During production use of the application plain vanilla > log4j provides no method for selectively turning debug logging on or off. > The only option, therefore, is to bounce the application server to turn > debug logging on by modifying the log4j.properties file, then bouncing the > application server once again to turn the logging back off. > > Debug Settings Logging > > Closely related to the previous paragraph is the ability to see the > current log4j settings. If good, informative debug messages are coded > into the application, then leaving DEBUG enabled for long periods of time > can easily result in huge log files. In the extreme, this in itself can > destabilize a production system by consuming all available disc space. The > plain vanilla log4 code has no simple mechanism for displaying the current > settings. > > Flexible One Line Instantiation > > When properly applied to a code base, Logger instance will be created in > almost every class in the system. Because it is so frequently used, it is > important that it be employed in as simple and as efficient a manner as > possible, preferable with a one line instantiation statement that ensures > the proper initialization of the Log4j system at the application level. > Log4j Extension Recommendations > > The following section contains a set of extensions (code) that if > implemented will maximize the benefit of Log4j use in the application, and > will address some of the above mentioned issues. > Implement a Log4j Utility Class > > A Log4j utility class should be developed with the following features. > For the purpose of this discussion, this utility class will be referred to > as Log4jUtil. > > • A set of static methods very similar to the Logger getLogger methods > provided by the basic Logger class, but with a few enhancements. The > following getLogger methods should be provided: > > o Logger getLogger(Class myClass) > > This method is designed for creating class level Logger instances by > simply calling Log4jUtil.getLogger(MyClass.class). This method will call > the Log4jUtil.init() method,then simply call > Logger.getInstance(myClass.getName()). > > o Logger getLogger(Object thisPtr) > > This method is designed for creating instance level Logger instances by > simply calling Log4jUtil.getLogger(this). This method will call the > Log4jUtil.init() method,then simply call > Logger.getInstance(thisPtr.getClass().getName()). > > The standard Logger.getInstance() method should never be used in the > application code base. Instead, all Logger instances should be created via > the use of one of these two Log4jUtil static methods. Why? Because this > ensures that the Log4jUtil.init() method is always run correctly before > any use of Log4j. > > • The static Log4jUtil.init() method that is called by both of the above > described getLogger methods is critical to this approach, because it is in > this method that we ensure that the Log4j environment is properly > initialized. The code in this init() class must perform the following > actions. > > o Resolve the full path of the log4j.properties file via inspection of the > standard log4j.configuration environment variable. If the file cannot be > located, a fatal exception should be thrown so that the application cannot > run without proper logging initialization. > o Load the properties file using the standard log4j procedures. > o Document the initial settings by calling the Log4jUtil document method > described below. > o Instantiate and activate the configuration file watchdog class described > below. This activation enables the automatic reconfiguration of the log4j > settings at runtime without the need to bounce the application. > > • The Log4jUtil class should contain a “print” or “toString” or “document” > method that will produce a nicely formatted String that documents the > current logger settings. These settings are obtained via the standard > LogManager.getCurrentLoggers() method. > > Implement a Configuration File Watchdog Class > > In order to extend the log4j system use so that it will automatically > detect changes to the log4j.properties file at runtime and reload the > properties, a configuration file watchdog class should be implemented and > initialized in the Log4jUtil.init() method as described above. > > The standard Log4j package contains a nice utility class named > FileWatchdog that provides most of this functionality out of the box. > Simply use the FileWatchdog class as the base class for a custom watchdog > class, then implement the required doOnChange() method. > > The doOnChange() method simply reloads the log4j.properties file, then > calls the above described “print” method to document the new settings that > were just loaded from the modified properties file. Producing > documentation of the new settings each time the file is changed is > important, because this allows the production log file to be monitored > when troubleshooting a production problem. > > The recommended delay value for the watchdog class is 1 minute. This is > infrequent enough that it will not cause any performance degradation, but > frequent enough to allow near real time modifications of the log settings > when diagnosing a production problem. > > > Log4j Application Recommendations > > The previous section describes additional software that will enhance the > basic out of the box Log4j system. The following section contains > suggestions on how the Log4j application should be used for maximum > effect. > > Do NOT Use Logger.getLogger! > > In order to ensure the Log4j system is initialized in the proper manner, > it is critical that the basic Logger.getLogger() method not be used, as > this bypasses the proper initialization of the Log4j usage within the > application. > Implement For Long Term Use > > Logging is certainly very useful during initial code development, but if > logging use is not specifically designed for long term use, its overall > value to the system will be severely marginalized. At some point in the > development process, the developer of each module should carefully > evaluate the use of logging statements in each class. This should also be > part of any formal code review sessions performed on each class. > > The following are suggested questions to ask during this code evaluation > process: > > • Six months after this code is in production, if a problem arises, will I > be able to turn on DEBUG and get detailed information on the operation of > this class or method? > • Will the information output by any DEBUG statements in this code be > meaningful to anyone other than the original developer? > • Is the output from the message formatted well enough to convey > information without having to perform a detailed study of the actual > source code in able to understand its meaning (Example: Do > “log.debug(“MyClass status = “ + getStatus())” instead of simply > “log.debug(getStatus())”). > • Does the information output by any DEBUG statements contain a sufficient > level of detail to allow accurate and complete diagnosis of module/method > operation? Remember that once the software is in production, adding > another line of code to log additional information is generally not an > option assuming careful QA and release procedures are followed. > • Are all but the most trivial log.debug statements protected by a “if > (log.isDebugEnabled())” block? The Logger class is carefully designed and > very efficient at minimizing any processing if DEBUG is not enabled for > that particular logger. But if the String argument passed to the log.debug > statement itself is complex, this in itself can impose significant costs > in runtime performance, and should be avoided. > > > Remove Any Short Term Debug Messages > > At the end of the development phase of the project and before deployment > to the production system, any log.debug statements that were introduced > into the code base purely for use by the developer should be removed. A > statement such as log.debug(“Got here”) rarely has any use once the code > is in production. > > “Verticalize” The Log4j Use > > A well designed software application normally has many implementation > layers. For example in a servlet or Struts application, there are top > level servlet or action classes that are essentially the “main program” > for that particular application function, and there are normally multiple > layers of reusable code below this top level layer that also have > considerable complexity that may need to be monitored and diagnosed using > log output. > > A very standard way of creating a Logger instance for a given class is to > have a class level Logger instance defined as follows: > > Private static final Logger log = Log4jUtil.getLogger(MyClass.class); > > But consider the implications of this style of usage if this class is a > utility class that is used in a web application that contains 200 screens > and therefore 200 JSP pages, servlets, or Action classes. If you turn on > DEBUG fort this class to troubleshoot a single screen that is problematic, > your log file is suddenly flooded with thousands and thousands of DEBUG > level messages that are output by every one of the 200 screens in this web > application. This not only can severely impact performance in a heavily > used web application, it also makes the job of locating the particular > debug message for the particular screen of interest very difficult and > time consuming. > > A far better approach is to verticalize the use of Log4j by following > these suggestions when using log4j in reusable classes within the > application: > > 1. Use the getLogger(MyClass.class) method of instantiating a Logger > instance for “top level” classes such as Struts Action classes, servlet > classes, or .jsp files. This allows DEBUG to be enabled for very specific > functionality within the application. > 2. For utility classes that are stateful, i.e. an instance is created and > then a series of method calls are performed on the instance, pass in a > Logger instance as a part of the constructor for this utility class. Doing > this in the 200 screen web application mentioned above makes it possible > to turn on DEBUG output from this utility class, but only when that class > is used for a single portion of the application, not for all use within > the application as described above. > 3. For static methods of utility classes, pass in a Logger instance as a > parameter to the static method. Once again, this technique allows DEBUG > output to be obtained from a very highly used utility method but only in > conjunction with a single top level module of interest. > > > Class Hierarchy Use > > In a good object oriented design there are frequently base classes that > are then extended one or more levels by derived classes. Significant > functionality is often encapsulated into these base classes for reuse by > the derived classes. > > If the Logger instance used in a base class is created using the standard > getLogger(MyClass.class)method of instantiation, turning on DEBUG for this > logger suffers the same problem as addressed in the previous section; too > much information is logged because logging is turned on for all instances > of all derived classes. In addition, the logger name typically displayed > in the log file will be the name of the base class, not the name of the > derived class, which makes the determination of which message comes from > the derived class of interest hard to determine when studying the log > file. > > In this usage scenario, the recommended approach is to use an instance > level Logger instance in the base class instead of a class level (i.e. > static) instance. This instance level should be created in the base class > constructor simply by doing a Log4jUtil.getLogger(this) call. Note that > since the actual class type of the this pointer is that of the derived > class not the base class, the logger will actually be associated with the > derived class and not the base class, thus producing more informative log > messages and allowing more detailed control when enabling/disabling DEBUG > in the application. > > -----Original Message----- > From: ennidhi [mailto:psatishb...@hotmail.com] > Sent: Friday, January 22, 2010 8:23 AM > To: log4net-user@logging.apache.org > Subject: log.txt > > > Hi, > I have implemented the log4net in my project. I have created the log > file > using the rollingfileappender. My log file contains mostly info and few > errors. I wonder is it the right way to implement? since I have not used > warn fatal error etc. I only used info, error and debug. I am attaching > the > log for the reference. http://old.nabble.com/file/p27273055/log.txt > log.txt > > And I have given settings like this in the web.xml. Is it ok to make > this > size files? I know it depends on the BA but out of curiosity I am asking > this question. > • Maximum size occupied by the logs would be 50MB *10 = 500MB. > -- > View this message in context: > http://old.nabble.com/log.txt-tp27273055p27273055.html > Sent from the Log4net - Users mailing list archive at Nabble.com. > > > -- View this message in context: http://old.nabble.com/log.txt-tp27273055p27929728.html Sent from the Log4net - Users mailing list archive at Nabble.com.
