Error: Macro BackLinksMenu(None) failed

compressed data is corrupt

Error: Macro TicketQuery(summary=CORE_LOGGING_R1, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed

current transaction is aborted, commands ignored until end of transaction block

Analysis

Overview

At present we use log4j for logging. Although it has several logging levels that allow us to sort information according to its significance, it is difficult to use different settings for different modules/packages/classes. We'll develop our own logger which will be more flexible and will give us more control over the output information.

Task requirements

Characteristics of the new logger:

• logging levels (similar to those of log4j)
• filter - a list of pairs (prefix, level) Each pair specifies the minimum logging level for a particular module/package/class...
  The effective logging level for a given class is determined by the pair with the longest prefix that is a prefix of its qualified name.
• targets - places to output logging information, for example a file or the console
  Each target may have its own filter.

Functionality:

• log a message with an explicitly specified log level
• some helper methods to log a message with the appropriate log level, for example error(String msg), warn(String msg), info(String msg)
• set/change the filter
• add a target
  There should be an option for the target to receive all previuos log messages that pass through its filter.

Task result

The result of this task is source code.

Implementation idea

• Unlike log4j we won't have a hierarchy of loggers, but a single static instance.
• It could keep its filter in a lexicografically sorted list and use binary search to find the effective logging level for a given class.
• When a message is logged, it should determine the caller class and its logging level and check whether the message passes through the filter or not.
• If it does it can be added to an intermediate list of log messages, from where it will be given to the targets if necessary.
• There is no need to write the message immediately after it is received.

Related

How to demo

Design

A new package will be created - org.sophie2.core.logging

Log messages will be encapsulated in LogEntry objects which will contain the message itself and some additional information about it:

• level (int)
  This attributes determines the relative importance of the log message. There will be some predefined level constants in the SophieLog class - fine, trace, debug, info, warn, error and fatal (in increasing order of importance). The level of a message will be used to determine whether it should be recorded in a particular target or not.
• time (long)
  The system time (in milliseconds) when the message was logged.
• source (StackTraceElement)
  This attribute will contain information about the caller - class, method and line number that logged the message.
• throwable (Throwable)
  An attached Throwable object (may be null)
  

In order to create a new LogEntryObject, one should provide log level, message and optionally a throwable. The message can be in the form of a format string and arguments (like in java.util.Formatter). The other attributes will be determined automatically.
There will be a private static helper class StackTracer responsible for finding the source of the log message. It will find a StackStaceElement of the appropriate depth using a native method.
The LogEntry class will provide a method converting it to a formatted string. The format will be the following:

[<level>] <classname> : <message>
<Throwable stacktrace>

The LogTarget interface represents an output destination for log messages, for example a console or a file. It has two methods:

• putEntry(LogEntry e) which processes log entries (or ignores them)
• close() which is responsible for freeing system resources, such as memory, output streams and open files.
  

It is implemented by MemLogTarget and OutputStreamTarget.

MemLogTarget is a singleton representing the main log target of SophieLog. It keeps lists of all logged messages and all targets and provides methods for adding targets and processing messages (which includes passing them to the other targets). When a new target is added, there is an option for it to receive all previously logged messages that interest it.

OutputStreamTarget class represents a target that writes messages to a stream. In order to do this asynchronously (and not block the application) it uses a BlockingQueue to store messages that should be logged and a new thread to log them. In the close() method it is important to empty the queue, flush the stream and the writer and close the stream.

The implementation will follow this diagram:

The main class is SophieLog. It contains static methods for management of targets and for logging messages.

Implementation

^{(Implementation results should be described and linked here (from the wiki or the repository))}

Testing

Comments

^{(Write comments for this or later revisions here.)}