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.
