Computer software framework and method for logging messages

[0002] The present invention is a computer software framework and method that provides a means to log messages to files, consoles, databases, and other destinations and combines the functions of log file formatting, message multicasting, message filtering, message severity processing and log file management.

[0003] Message logging is an example of a general application facility that is typically needed in development of software code and applications to assist with testing, debugging, trouble shooting, and the like. Computer applications typically log (e.g., write, display, send, etc.) messages to a variety of destinations such as files, screens/user displays, dialogs, databases, remote servers, consoles, and the like using various message formats. An enterprise-wide computing system typically has a number of separate computing systems linked together and hosting a variety of computer applications, leading to problems such as inability of applications to log to multiple destinations simultaneously and inconsistent message formatting for messages written to the same log. Thus, a need exists for a means to uniformly log messages across an enterprise-wide computing system to aid in the development and maintenance thereof. The current invention addresses this need by encapsulating message logging and related functions, thereby providing a uniform application programming interface (API) to the various applications and making the task of message logging much simpler from an application's perspective. The invention abstracts the concept of a log, thereby presenting a consistent API to developers regardless of the log file type (e.g., a file log, a console log, a group log, etc.).

[0004] The present invention discloses a message logging framework, comprising a log object created by a destination log class extending a log base class and the log base class implementing a log interface, wherein the log base class comprises a method for formatting a message and the destination log class comprises a method to log the formatted message to a destination log. In a preferred embodiment, the log base class further comprises a method for filtering the message by comparing a severity attribute of the message to a filter severity criterion, wherein a message that conforms to the filter severity criterion becomes a filtered message and is (or alternatively is not) logged to the destination log and a message that does not conform to the filter severity criterion becomes an unfiltered message and is logged to the destination log. The present invention also discloses a message logging framework, comprising a group log object created by a group log class extending a log collection class and implementing a log interface, wherein the group log class comprises a method to log a message to a plurality of destination logs. In a preferred group logging embodiment, each of the plurality of destination logs further comprises a log object created by a destination log class extending a log base class and the log base class implementing a log interface, wherein the log base class comprises a method for formatting the message and the destination log class comprises a method to log the formatted message to the destination log.

[0005] The present invention further discloses a method for logging a message, comprising forming a destination log object by a destination log class extending a log base class and the log base class implementing a log interface; formatting the message; and logging the formatted message to a destination log via the destination log object. In a preferred embodiment, the logging method further comprises filtering the message by comparing a severity attribute of the message to a filter severity criterion, wherein a message that conforms to the filter severity criterion becomes a filtered message and is (or alternatively is not) logged to the destination log and a message that does not conform to the filter severity criterion becomes an unfiltered message and is logged to the destination log. The present invention also discloses a method for logging a message, comprising forming a group log object by a group log class extending a log collection class and implementing a log interface; and logging the message to a plurality of destination logs via the group log object. In a preferred group logging embodiment, the method further comprises forming a destination log object by a destination log class extending a log base class and the log base class implementing a log interface; formatting the message; and logging the formatted message to the destination log via the destination log object.

[0006] FIGS 1A-1D and 2A-2B are an object model, also referred to as a class diagram, of the message logging framework of this invention.

[0007] The current invention provides a business computing component with a common interface to a variety of message logs such as a console log, a file log, and a group log. The invention provides a framework and method for logging messages to these various logs while maintaining a common interface for the existing business functions/applications being carried out by the business computing component. One of the advantages of the current invention is that it provides a single interface to perform message logging that would otherwise require two or more separate interfaces. In other words, the invention encapsulates the capabilities of multiple logs into a single interface.

[0008] Log as used herein means any type of message storage software device or medium, including datafiles, databases, memory chips, hard drives, floppy drives, magnetic storage media, optical storage media, and the like. Preferably, the log is a file or a database, which can be either a relational or object database. Message as used herein means any type or combination of data, information, words, symbols, signals, communications, strings, outputs, and the like generated by a computing system. Preferably, the message comprises a text string with one or more attributes attached to it such as a base severity level/description attribute and/or an options attribute containing information such as user identification, transaction type, application type, etc. Formatting a message means amending the text string of the message to remove information or to include additional information, for example by incorporating the information contained within a message attribute into the message text string. Preferably, the attributes are in the form of key/value pairs in a hashtable. Message logging is the act of sending a message to a log.

[0009] As shown in FIG. 1A, the public interface to the message logging framework is log interface 10 and log base class 15. An interface (also known as a message interface) is a communication surface that determines the signals (e.g., calls) that can pass through the surface; in other words, the interface defines which calls an object will respond to. Log base class 15 is an abstract class that implements log interface 10. The implementation of an object consists of a class definition that implements the object interface. As used in object technology, a class defines the methods and variables for a particular type of object; all objects of a given class are identical in form and behavior but contain different data in their variables. An abstract class is a class that contains one or more abstract methods (i.e., a method that has no implementation), and therefore can never be instantiated. Abstract classes contain useful information and methods and are defined so that other classes can extend them and make them concrete by implementing the abstract methods. Accessors are the methods on a class that provide access to the variables of the class (for example, get and set commands). The methods and variables comprising each class are shown in FIGS. 1A-1D, and it will be understood that these methods and variables may be modified by one skilled in the art without departing from the scope of the present invention. Log base class 15 provides the ability to enable or disable the logging function in addition to message filtering through severity levels and message formatting.

[0010] Console log class 20 in FIG. 1D, file log class 25 in FIG. 1B, and null log class 30 in FIG. 1D are classed representing specific types of logging destination (e.g., specific log types), each of which extends log base class 15. Thus, log base class 15 abstracts console log class 20, file log class 25, and null log class 30. Console log class 20 logs messages to a user console or display (referred to as standard out or standard error), file log class 25 logs messages to a file, and null log class 20 serves as a place holder and does not write a message to any location, which allows logging to be transparently disabled. Other specific logging destination classes may be added, for example logs associated with specific types of software or hardware such as a WebLogic server log, a remote CORBA or JMS logging server, or a database.

[0011] Log base class 15 provides a means to process messages based upon their severity attributes, for example through filtering or monitoring methods. Messages may be filtered based upon information contained in the severity attribute of the message. Filtering messages based upon their severity allows a developer to reduce the total number of messages being logged (i.e., reduce log file clutter), which is useful in reducing log storage requirements or focusing on critical or urgent types of messages. Furthermore, the severity attributes of messages can be monitored and used to trap and event and trigger other events. For example, if a high severity message is detected, a notification (such as an electronic page or e-mail) could be sent to a system administrator. Another example is to use the severity attributes as search indexes of the messages residing in a log. The severity attribute typically contains a description of the severity of the message, and this description can be appended into the message string during formatting, as discussed below. Following logging of the formatted message into a log, the severity portion of the logged message can then be used as a search index to find messages within the log. While any type of severity description could be used, the following is an exemplary listing of six descriptions, including both a severity level name and corresponding numerical indicator (i.e., levels 0 through 5, where 0 is the least severe and 5 is the most severe):

[0012] TEMP (0)—Temporary message used for quick testing or prototyping.

[0013] DEBUG (1)—Message used for debugging or testing.

[0014] INFO (2)—Indicates an informative message.

[0015] WARNING (3)—Indicates a warning message.

[0016] ERROR (4)—Indicates an error message that may be recoverable.

[0017] FATAL (5)—Indicates a fatal error message that is not recoverable.

[0018] Using these severity descriptions, messages may be filtered so that only messages meeting (or conversely, not meeting) the designated filter severity criterion of the filter will be logged. Filtering may be accomplished by any known means of comparing a message's severity level against the designated filter severity criterion. For example to log high severity level messages, the message is logged if the message's numerical severity level is greater than or equal to the filter's severity numerical level for the log. Message filtering may be used alone or in combination with the other logging functions described herein, and may be used on any type of log.

[0019] Log base class 15 provides a means to format messages to obtain a consistent structure and appearance for generated logs containing the logged messages, which helps to provide uniformity across a computing system. In carrying out the formatting function, log base class 15 calls a formatter, typically an object containing a method for appending additional information to the text string of the message. Referring to FIG. 2A, formatter subclasses implement formatter interface 35. Any type and number of formatter subclass may be used to represent information for amending a message prior to logging, and preferred formatter classes include time stamp formatter 40, severity formatter 41, application formatter 42, user formatter 43, and transaction formatter 44. Time stamp formatter 40 amends the text string of the message to include a time stamp (for example when the message is received). Severity formatter 41 amends the text string of the message to include the severity description contained in the severity attribute of the message. Likewise, application formatter 42, user formatter 43, and transaction formatter 44 amend the text string of the message to include identification of the application, user, and transaction, respectively. Any desirable type and number of formatters may be used such as a user identification formatter or application name formatter to identify to source of the message. In a preferred embodiment, the logging framework applies a chain of formatting operations to a log. The formatters are chained together such that when a message is sent to a log, the log iterates sequentially through its chain of formatters (typically in the order in which the formatters are added to the chain) and applies the formatting rules to the message before the message is displayed or written. Log file formatting may be used alone or in combination with the other logging functions described herein. Where messages are preformatted by the sender, it may not be necessary to format the message prior to logging the message.

[0020] Group log class in FIG. 1C provides a means to multicast messages to a plurality of logs, that is to write a message to multiple destinations. In other words, group log class 50 abstracts the underlying destination logs (such as console logs, file logs, etc.), thereby allowing an application to make a single logging call to the group log which results in the message being logged to each of the underlying destination logs. Group log class 50 may contain any number of destination logs, for example a collection containing a console log, a first file log, a second file log, etc. Group log class 50 implements log interface 10, and thus may be treated the same as any other log implementing log interface 10 (e.g., an implementation of console log class 20, file log class 25, or null log class 30). Group log class 50 extends log collection class 55 in FIG. 1C, which is an abstract class containing useful information and methods for creating and maintaining collections of logs (for example, methods to store and retrieve individual destination logs). Thus, group log 50 is a type of log collection. Message multicasting may be used alone or in combination with the other logging functions described herein.

[0021] Like group log class 50, log manager class 60 in FIG. 1C extends log collection class 55, and therefore log manager 60 is a type of log collection. More specifically, log manager class 60 is a collection of underlying destination logs (such as console logs, file logs, etc.) each of which has a logical name. As a helper or utility class, log manager class 60 provides access to the underlying destination logs by their logical names, which further promotes the efficient logging of messages.

[0022] As shown in FIG. 2B, formatting exception class 65 and logging exception class 70 are standard error message classes (i.e., throwable exceptions) corresponding to common errors occurring in the formatting and logging functions, respectively. Duplicate log key exception class 72, log message exception class 74, and log not found exception class 76 are shown as representative members of logging exception class 70.

[0023] The present invention may be deployed at any architectural level requiring message logging capabilities within an enterprise wide computing system. In a preferred embodiment the messaging framework of the present invention is deployed on an application server, which may be any of a number of commercially available computer servers appropriate for accessing backend systems (e.g., databases, mainframes, customer premises equipment, and the like) to serve the needs of a client or group of clients (e.g., a user station, another server, etc.). A preferred application server is a WebLogic server available from BEA Systems.

[0024] While the code examples herein are written in the Java programming language, which is available from Sun Microsystems Inc., it is understood that other suitable programming languages may be used as will be readily apparent to one skilled in the art. Furthermore, it should be understood that the code examples are in skeleton or outline form, and are not necessarily intended to be in complete executable form, provided however that one skilled in the art could easily tailor executable code based upon these examples. The italicized text following the double backslashes (i.e., “//”) is commentary text.

[0025] In this example, a console log is created without specifying the default severity or filter level. In which case, the console log sets the default severity and filter level to the lowest level, TEMP. Since the filter level is set to the minimum value, all messages regardless of severity will be logged. Logging is performed directly through the instance of console log All log messages will have time stamps pre-pended to them by the time stamp formatter.

[0026] In this example, logging is performed directly to a console log which has been configured with a timestamp formatter, severity formatter, as well as a user formatter. The user formatter will check each call to log message for optional information in the options Hashtable. If the Hashtable contains a key of “userid” the formatter will format the logged string with the value of this field.

[0027] In this example, a console log is created that will log all messages to standard error with the filter level set at LogBase.DEBUG. Three messages are then sent to the log. The first will not be logged, because it is sent with TEMP severity (TEMP<DEBUG). The second will be logged because it is sent with WARNING severity (WARNING>DEBUG). The third will not be logged because, although it is sent with WARNING severity, the log itself has been disabled.

[0028] In this example, three logs are created: a file log, a console log, and a group log. The file and console logs are configured with formatters, and then are added to the group log. Logging of different severity levels is then performed directly to the group log. The correct output should show the log messages sent to both the file log and the console log, formatted accordingly.

[0029] In this example, messages are logged via a LogManager. A console log and a file log are created and added to a LogManager with their own logical names. The console log is added as the default log. Once added messages are logged via the log manager and the logs logical name. A message is also logged without specifying a logical log name, therefore being sent to the default log.

[0030] This method shows how specific log destination types can be passed and manipulated using their higher-level log interface type. In this example, an instance of a class named SomeOtherClass containing a log member variable and a trigger( ) method is instantiated. SomeOtherClass is representative of classes from other frameworks or application code that intend on integrating and utilizing the Logging Framework. The log member variable is initialized to a NutlLog. The triggers( ) represents a method that would normally perform logging operations to the log member. The main method creates and instance of SomeOtherClass and calls its triggers( ) method. It then replaces the instance's log with other types of logs, and calls the trigger method again each time, showing how the log can be transparently replaced.