From RTSC-Pedia
![]() | [printable version] | offline version generated on 25-Jun-2010 20:06 UTC | ![]() |
Extending xdc.runtime Logging/Example 2
A logger that leverages the event's Diags mask
The Events Diags Mask
When a logger receives an event it is passed:
- The event id
- The module id of the module which logged the event
- The event arguments
- The event's diags mask
The first example demonstrated how events could be filtered using the event id and arguments. In this example, we'll look out how events can be filtered using the event's diags mask.
xdc.runtime Logging already has built-in support for enabling and disabling different event categories in the diags mask, and events are filtered at the Log call site based on the diags mask before they are even passed to the logger. However, it is up to the logger whether to support filtering of events based on event level. For an introduction to event levels, see Example 5 in the xdc.runtime Logging article.
In addition to the event levels, it is possible for the logger to do more advanced filtering or handling of events based on the event's category.
The LoggerBuf Implementation
The LoggerBuf implementation serves as a good example of these advanced filtering and handling abilities.
LoggerBuf provides two features in this area:
- It implements the xdc.runtime.IFilterLogger interface, and as required by that interface, provides full support for filtering of events by event level, with different filtering levels for each category.
- It supports routing of status events to a separate logger instance. Since status events (errors and warnings) can be critical to receive, and can be easily overwritten by more common events, it can be important to send these events to their own separate logger where they can be preserved.
app.cfg | |
| var Diags = xdc.useModule("xdc.runtime.Diags"); var Log = xdc.useModule("xdc.runtime.Log"); |
![]() | [printable version] | offline version generated on 25-Jun-2010 20:06 UTC | ![]() |