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

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.)}