This project has moved and is read-only. For the latest updates, please go here.

See also

Design of CuttingEdge.Logging

The CuttingEdge.Logging framework includes the following features:
  • A simple and consistent way of logging event information;
  • An easy XML configuration model based on the .NET 2.0 Provider Model;
  • A code-based configuration model;
  • A configurable fallback mechanism for situations where a provider fails to log;
  • Extensibility through custom logging providers.

Design Highlights

The following figure illustrates the design of the CuttingEdge.Logging framework.

Logging Façade

The Logger  class is a façade that sends log information to a configured logging provider. The Logger class has a collection of configured logging providers and has a default logging provider. All logging events are routed to the default logging provider, but clients can access the collection to use an alternative logging provider.

Logging Providers

The actual logging of events is done by a logging provider implementation. The framework consists of several default logging providers. All providers inherit from the LoggingProviderBase abstract base class. A custom logging provider can be made by inheriting from this base class and registering your type in the configuration file. See the configuration examples for more information about configuring.

Fallback Providers

The default behavior of CuttingEdge.Logging is to let exceptions, caused by a failing provider, bubble up the call stack. The philosophy of CuttingEdge.Logging is that a failing provider is a serious problem and should not be ignored. This philosophy is one of the key differentiates between CuttingEdge.Logging and most other logging frameworks who simply sweep exceptions under the carpet.

To prevent exception from bubbling up the call stack, and possibly crash the application, CuttingEdge.Logging contains the notion of Fallback Providers. When a logging provider fails to log, the original event, and the exception thrown by the provider will be routed to the configured fallback provider.

In certain scenario's however, developers may want the application to be more robust and continue execution, even when logging fails. This can be the case when no suited fallback provider is available or that fallback provider could also fail. While these scenario's should be rare, the framework enables this scenario by the use of the TerminatorLoggingProvider. Events going through a TerminatorLoggingProvider, will get trashed and the application continues execution.

Log Information

While users of the framework can send logging information through convenient method overloads on the Logger class, logging providers work with a container for log information called LogEntry. While users can create LogEntry instances and send them to a logging provider, they will find the overload methods often more useful.

ILogger interface

All logging providers implement the ILogger interface. While this interface isn’t used in the main scenario’s, the interface can be useful in system designs where code is not allowed to use the static Logger class, but use a logger instance as part of a given context. By passing a ILogger interface, the caller can control and change the logged events, before he sends them to the underlying logger provider implementation.

More information

For more information about CuttingEdge.Logging, please visit the following links:

Last edited Aug 26, 2010 at 8:52 PM by dot_NET_Junkie, version 8