Provides a public interface which can send messages to the Plumtree Logging Toolkit.
See Logging Example for an annotated console application example, or refer to the more concise usage examples below.
When using the EDK in a web application context we recommend configuring the logging framework via Web.config (Microsoft IIS) or web.xml (Java servlet containers). The web application configuration files shipped with the EDK contain annotated examples of how to configure logging.
When outside a web application context we recommend that a single log management class
be declared within the project that will initialize the LogFactory
(possibly as
part of static initialization). This instance will provide instances of ILogger
and possibly define a set
of known component names for the application. This technique will help to avoid multiple initializations.
This name is set during initialization of the LogFactory
or configured in the web configuration file.
The logging application name is used as a shared identifier which allows Plumtree log receivers to pick up messages from the
logging application. All crawler, authentication, profile or search web services running in the same EDK web application
instance will have the same logging application name.
All ILogger
instances require a component name to identify the general context for a set of log messages.
A component is a conceptual unit within an application. A small application may have only a single named component.
It is reasonable to define component names as string constants that are localized in a log management class.
The Plumtree logging framework is designed to suppress logging if there are no listening applications.
For better performance, logging applications should use the ILogger
interface to find out if there any listening
applications before composing complex log messages.
For example:
if (logger.DebugEnabled) { // compose a diagnostic message logger.Debug( complex diagnostic message...); }
Similarly, the Plumtree logging framework will avoid internally composing formatted log messages when
there are no listeners. For this reason, ILogger
has numerous method overloads
which allow passing a format string and various Object
and numeric arguments. The
arguments will only be processed and composed into a log message if there is an active
listener for that log level. This helps avoid unnecessary string concatenation and makes for cleaner code.
Prefer this:
to this:logger.Debug("An error occurred when {0} attempted to access {1} (context {2})", user, resource, context);
logger.Debug( "An error occurred when " + user + " attempted to access " + resource + " (context " + context + ")");
using System; using Plumtree.Remote.Logging; namespace Plumtree.Remote.Logging.Test; { /// <summary> /// Provides an example of using the Plumtree EDK /// logging API. /// </summary> public class LoggingExampleLogUser { public LoggingExampleLogUser() : base() { } private static ILogger getLogger() { return LoggingExampleLogHolder.getLogger(typeof(LoggingExampleLogUser)); } public static Object createObjectFor(String customerName) { ILogger logger = getLogger(); logger.FunctionBegin("createObjectFor"); Object retValue = new Object(); logger.Info("Created new object for customer {0}.", customerName); if (logger.DebugEnabled()) { logger.Debug("Details of new object: {0}, runtime type {1}, customer {2}", retValue.ToString(), retValue.GetType().FullName, customerName); } logger.FunctionEnd("createObjectFor"); return retValue; } public static void Main(String[] arguments) { createObjectFor("Plumtree"); for (int i = 0;i < arguments.Length;i++) { createObjectFor(arguments[i]); } } } }
using System; using Plumtree.Remote.Logging; namespace Plumtree.Remote.Logging.Test; { public class LoggingExampleLogHolder { public LoggingExampleLogHolder() : base() { } private static bool logToNetworkWhenTrue = true; static LoggingExampleLogHolder() { LogFactory.Initialize("ExampleName", logToNetworkWhenTrue); } public static ILogger getLogger(Type loggingClass) { return LogFactory.GetLogger("LoggingExample", loggingClass); } } }
Class | Description |
---|---|
LogFactory | The LogFactory is the starting point for the EDK Logging API, it offers static methods to configure logging, query configuration properties, and obtain ILogger instances. |
Interface | Description |
---|---|
ILogger |
Defines the interface for logger instances, including logging methods and methods to test if various log levels are enabled. To create a logger object call Logging LevelsSeverity-Based Logging Levels
Supplemental Logging Levels
Logging Performance ConsiderationsTo minimize the performance cost of logging and avoid unnecessary work when constructing log messages use an overload of one of the logging methods which inserts values into a format string. The overloads help reduce string concatenation. Also wrap any complex message construction in a conditional block to avoid doing the work if there are no listeners at that log level, following the example in the namespace summary. |