slf Discussions Rss Feed

New Post: thread safety

PerrySharePoint — Thu, 09 May 2013 18:10:31 GMT

Is SLF thread-safe? If not, how does one use it safely from multiple threads potentially simultaneously?

New Post: How about .NET Framework support

sgryphon — Fri, 19 Apr 2013 14:03:00 GMT

Um, hello?

For a .NET facade, it's pretty strange that you seem to support a bunch of third party logging frameworks, but not the .NET Framework itself, i.e. System.Diagnostics, TraceSource, etc.

New Post: Releasing File Lock

benhelite — Fri, 15 Feb 2013 22:18:37 GMT

Hello everyone,

I have a program which uses SLF for logging. This program runs 24/7 and I would like to upload the log files to a remote server every night for later review.

My question is, how do I release the file lock for the log without closing the program?

I was hoping to suspend logging, upload the logs, either delete the log file or erase the contents, and then resume logging.

ILogger logger = LoggerService.GetLogger(typeof(TaskScheduler).FullName);

// Other initialization here

foreach (var task in managedTasks.OrderBy(t => t.Priority))
{
    if (task.NextRunTime <= DateTime.Now)
    {
        dataManager.CurrentStatus = AppStatus.Running;
        if (task.Name == "Log Sender")
        {
             logger = null;
        }

        // Run the task

        if (task.Name == "Log Sender")
            logger = LoggerService.GetLogger(typeof(TaskScheduler).FullName);

        dataManager.CurrentStatus = AppStatus.Idle;
    }
}

Currently, when I do this, I'm still getting an IOException because the file is still locked by the Task Scheduler.

Any ideas are appreciated.

Ben

New Post: Factory for BitLaboratory (Object Guy's) Logging Framework?

benmcclure — Sun, 27 Mar 2011 07:26:02 GMT

This is an old message, but I have the exact same issue...

BitFactory can be configured declaratively, and SLF can be configured declaratively, but it does not seem they can be configured declaratively together without a factory for creating BitFactoryLogger objects...

Unless I am missing something as well.

New Post: callsite is lost through NLogFacade

Mixmasterxp — Wed, 16 Feb 2011 04:11:53 GMT

Have this been fixed for NLog? Instead of importing the NLogFacade dll, I copied the 2 files into my project. Would this prevent callsite from working?

I set up logger in my global.ascx file as follows:

  //Setup logger
  LoggerService.FactoryResolver = new SimpleFactoryResolver(new NLogLoggerFactory());

Later down in my app, I log like this:

ILogger logger = LoggerService.GetLogger();
logger.Error("Exception: {0}", ex.Source);

My NLog.onfig:

<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <targets>
    <target name="file" xsi:type="AsyncWrapper" queueLimit="5000" overflowAction="Discard">
      <target name="FileError"
            xsi:type="File"
            fileName="${basedir}/App_Data/Logs/errors.txt"
            archiveFileName="${basedir}/App_Data/Archives/log.{#####}.txt"
            archiveAboveSize="10240"
            archiveNumbering="Sequence"
            concurrentWrites="true"
            keepFileOpen="false"
            encoding="iso-8859-2"
            layout="${longdate}|${callsite:className=true:fileName=false:includeSourcePath=false:methodName=true}|${message}"/>
      <target name="FileInfo" xsi:type="File" fileName="${basedir}/App_Data/Logs/info.txt"/>
    </target>
  </targets>
  <rules>
    <logger name="*" level="Error" writeTo="FileError"/>
    <logger name="*" level="Info" writeTo="FileInfo"/>
  </rules>
</nlog>

New Post: Using NLog.config

Mixmasterxp — Mon, 14 Feb 2011 00:56:19 GMT

Stupid question lol. Delete pls.

New Post: Reload configuration for configuration file on fly

wageoghe — Wed, 10 Nov 2010 22:23:44 GMT

You might also consider using Common.Logging. It supports (via the config file) telling log4net to configure and watch. It also supports putting the log4net configuration in the app.config file OR in a separate config file.

New Post: Reload configuration for configuration file on fly

alfrye — Mon, 08 Nov 2010 21:31:36 GMT

I am looking at using SLF and log4net as the logging framework on one of my projects. I am setting up the SLF and log4net configuration in my app,config file and everything loads and logs as excepted. However one of my requirements is to be able to change the log4net properties from my application and have the logger to use the new settings without reloading the application. In the past I have used the log4net xmlconfiguration configandwatch() method.

Is there a way to handle this through the SLF framework.

New Post: SLF with Windows Phone?

BeauGeek — Mon, 04 Oct 2010 18:23:38 GMT

Is SLF (or a future version) usable with Windows Phone 7?

Thanks.

Vikram

New Post: callsite is lost through NLogFacade

wageoghe — Fri, 10 Sep 2010 18:19:05 GMT

Building on my last comment, here is some code from Common.Logging that I think is showing the correct technique for preserving the code location. Note that declaringType is stored in the wrapping logger (in this case Common.Logging's Log4netLogger) and it is the type of their Log4netLogger (as compared to the use of the logger's base class that is used to make NLog's code location work correctly).

        /// <summary>
        /// Sends the message to the underlying log4net system.
        /// </summary>
        /// <param name="logLevel">the level of this log event.</param>
        /// <param name="message">the message to log</param>
        /// <param name="exception">the exception to log (may be null)</param>
        protected override void WriteInternal(LogLevel logLevel, object message, Exception exception)
        {
            Level level = GetLevel(logLevel);
            _logger.Log(declaringType, level, message, exception);
        }

New Post: Adding unique IDs to log messages

wageoghe — Fri, 10 Sep 2010 18:11:13 GMT

You can go to the log4net source repository here to find a log4net extension that shows how to extend log4net to include an event id parameter. Essentially they define an interface that is the same as (or similar to) ILog, with an additional eventId parameter. The implementation wraps a regular log4net logger. Each logging call creates a log4net LoggingEvent structure/class and adds an "EventID" property to the LoggingEvent's Properties dictionary. It then uses the regular log4net logger's Log method (which takes a LoggingEvent sturcture/class). To get the EventID to show up in the output, I guess you would just have to add the appropriate properties reference in the format string.

If SLF wanted to support the ability to log "event id" natively, one approach might be to declare an interface that is parallel to SLF.ILogger. It might be SLF.IEventIdLogger. It would have the same parameters as ILogger, with the addition of an event id, maybe as the first parameter like log4net did. Now, if someone wants to log event ids, they would request IEventIdLoggers (maybe you would need a parallel LogManager like log4net implemented in their extension) and log away. A similar technique could probably be used for NLog (put the EventId in the appropriate NLog context dictionary).

New Post: Expose logging context

wageoghe — Wed, 08 Sep 2010 21:05:39 GMT

Should slf "generically" expose the logging context (NDC, MDC, etc) of log4net and NLog?

For an example of a logging abstraction that does this, see the log4net and NLog abstractions at the Castle project. log4net and NLog loggers can be resolved as basic loggers (I think with an ILogger interface) or as "extended" loggers (IExtendedLogger). From what I can tell, the extended logger interface exposes all of the "context" information (stacks and dictionaries) that can be exposed on log4net and NLog. There is also a TraceSource based logger, but it is only exposed as ILogger. I'm not sure what would happen if you tried to access the extended information on a TraceSource based logger, maybe an exception, maybe it just doesn't support an interface.

Anyway, without exposing the logging context generically, one would have to resort to referencing the specific logging platform's LogManager to set the context, thus defeating the purpose of using the abstraction.

Of course, there is the inherent conflict between limiting the facade to capabilities available in all logging platforms vs implementing/exposing capabilities that are available in some, but not all, logging platforms.

New Post: using external config file with slf

vmlf — Sat, 28 Aug 2010 16:19:37 GMT

Due to the length and complexity of some log config files, it would be usefull if we could store it in an external file and have some way to point SLF to load it from there instead of the app config file.

New Post: Adding unique IDs to log messages

wageoghe — Mon, 23 Aug 2010 16:30:39 GMT

It depends on what you mean by this comment "IT support team have requested that each logged message (above DEBUG) has some form of unique ID". Do you mean that every message that is logged by tagged with, essentially, an sequentially increasing id? So, the logged messages would have a field that would go like 1, 2, 3, etc as statements are logged? Judging by the rest of your comment (about defining an enum of log IDs), it sounds like you are asking about something like "event id" which helps describe the actual message being logged. So, you could define "log ids" or "event ids" like this (enum or const, or whatever you prefer):

public class AppEventId
{
  public int Startup = 0,
  public int Initialize = 1,
  public int Shutdown = 2,  
  public int Enter = 3,  
  public int Exit = 4,
  public int DatabaseLoginFailed = 5,
  public int FooServiceNotAvailable = 6,
  public int BarServiceNotAvailable = 7,
  public int LoginFailedOnce = 8,
  public int LoginFailedTwice = 9,
  public int LoginFailedThriceUserLockedOut = 10
};

With these ids, and with an api that accepts ids (like System.Diagnostics TraceSource.TraceEvent), you can write code that gives logging messages some additional context.

int maxAttempts = 3;

TraceSource ts = new TraceSource("MyTraceSource");
ts.TraceEvent(TraceEventType.Information, AppEventIds.Enter, "Enterning XYZ");

bool userLoggedIn = false;
int attempts = 0;

while (!userLoggedIn && attempts < maxAttempts)
{
  userLoggedIn = GetUserLoginInfo();
  if (!userLoggedIn)
  {
    int id = 0;
    switch (maxAttempts)
    {
      case 0:
        id = AppEventId.LoginFailedOnce;
      break;
      case 1:
        id = AppEventId.LoginFailedTwice;
      break;
      case 2:
        id = AppEventId.LoginFailedThriceUserLockedOut;
      break;
    }
    ts.TraceEvent(TraceEventType.Warning, id, "Login attempt failed");
    throw new Exception("Login failed");
  }
  attempts++;
}
ts.TraceEvent(TraceEventType.Information, AppEventId.Exit, "Login successful");

Here is a question from StackOverflow that seems to be asking about event ids in the same context and meaning that you are asking:

http://stackoverflow.com/questions/1637464/what-are-best-practices-for-event-id-management

Some time ago I saw another post on StackOverflow where someone made a comment about defining event ids in a manner similar to the "theory of reply codes" used in SMTP.

http://stackoverflow.com/questions/576185/logging-best-practices

See the "Other recommendations" under the first answer (the answer by "Sly", just in case the answers are ever reordered) for a brief discussion of how one might structure event ids.

I think that there are a couple of issues regarding the event id:

1. If an organization/product wants to use event ids, then they have to define the ids and manage them somehow. This seems to be part of the problem you are describing. Some ids get defined. They are used in logging messages. Someone writes more code and wants to log a message and should make a new id, but is to lazy to do so. Instead, they use an existing id that might be misleading to someone reading the log.

2. If an organization/product wants to use event ids, it is more awkward to log them using popular logging frameworks like log4net and NLog. The "normal" logging functions (Logger.Info, ILog.Info, etc) don't accept an id parameter. Also, the more generic "Log" functions also don't seem to accept an "event id" parameter (in the same sense as the EventID accepted by TraceSource.TraceEvent). It looks like the only way to get an EventID logged is to use either the MDC, NDC, GlobalContext, or ThreadContext objects (whichever one is appropriate) on the logger/manager.

See this StackOverflow question/answer for one example of how to get an "event id" to show up in a log4net log:

http://stackoverflow.com/questions/2290102/log4net-eventlogappender-log-event-id

(In this question they seem to be asking about the EventLogAppender, but I see no reason why someone might not want to log event ids in other logging targets like files, etc).

(Note that I have not actually used either of these logging platforms, except for recently trying out NLog). Anyway, the EventID could be stored in the appropriate dictionary and then could be referenced in the formatting string so that the output contains the ID.

So, what to do? I'm not sure what SLF can do to help with problem 1. It seems that the ids have to be defined and managed somewhow. Once that is solved, it should be straightforward enough for a developer that wants to log a message to determine what the appropriate id is. If there is not an appropriate, he/she should probably define a new one (depending on local standards/procedures). I suppose that SLF could have some sort of event id validation facility where an application/library can "register" "valid" event ids with SLF and then any time an event id is passed to SLF via an "event id" parameter in a logging call, SLF could verify that the id is a valid one. This would give a development shop the ability to catch the use of nonexistent event ids, but would not help in the case of "wrong" event id being used in the wrong place. I would say leave the event id definition and management up to the development organization. Maybe SLF should only provide a way to explicitly pass the event id parameter and get it logged?

It seems like SLF could help with problem 2. Maybe by providing some overloads that allow the specification of an event id in the logging calls (ILogger.Info(), ILogger.Warn(), etc). With that in place, there is now a uniform way for people to use SLF and to be able to log event ids. For TraceSources (if natively supported by SLF), the implementation would be simple enough. Simply pass the event id to TraceSource.TraceEvent via the event id parameter. Done. For log4net and NLog, the problem is trickier. Since there is (from what I can tell) not an explicit "event id" parameter available in the logging functions for those platforms, then the event id would have to be passed by convention, perhaps by adding a key/value pair to the appropriate dictionary (maybe called "EventID"??) containing the parameter name ("EventID") and value (the event id itself). If the person using log4net or NLog as their underlying platform wants to use the event id parameter, he/she would have to configure the formatting string(s) to reference the "EventID" parameter.

Another issue with adding the ability to log event ids is that now you need a lot more overloads of the logging functions. I suppose you could choose to restrict the use of the "event id" parameter to a limited set of functions or you could make the event id parameter optional or have a default value. I do notice that SLF.ILogger does have a "Log" function that takes a LogItem structure that has an event id member. This means that people using SLF today could program to the Log function and populate the LogItem structure explicitly. Maybe it is not so bad if you don't have a large number of logging statements that want to log the event id? That is ok, I guess, but it suddenly makes the application's logging code more verbose:

// Using ILogger.Log and LogItem makes this look more like old LAB logging examples.
ILogger logger = SLF.GetLogger("HelloWorldLogger");

LogItem item = new LogItem();
item.Message = "Hello World!";
item.LogLevel = LogLevel.Warn;
item.EventId = 1001; //Let's just hardcode the event id for now
item.LoggerName = logger.Name;

logger.Log(item);

//Compare with being able to pass event id explicitly:
ILogger logger = SLF.GetLogger("HelloWorldLogger");

logger.Warn("Hello World!", 1001);

If I had to vote, I would say that adding a common way to log event ids across the logging platforms supported by SLF (or custom factories/loggers implemented by users of SLF) would be useful.

Sorry for the long (and late) post, hope it is helpful.

New Post: Extending the ILogger and LoggerBase

wageoghe — Fri, 20 Aug 2010 21:13:50 GMT

I agree with providing the IsXXXEnabled functions for the ILogger interface. It is certainly useful when some extra processing is required to generate some values to be logged, but that processing is required ONLY when logging. The entire code block that performs the processing can be short-circuited by an upfront IsXXXEnabled.

void Matrix BuildTransform()
{
  Matrix m = DoSomeWorkToCalculateMatrix();

  logger.Info("Matrix = {0}", m);

  if (logger.IsInfoEnabled)
  {
    IEnumerable<Point> pts = GetTestPoints();

    logger.Info("Points before transform");
    foreach (Point p in pts)
    {
      logger.Info(p);
    }
    logger.Info("Points after transform");
    foreach (Point p in pts.Transform(m))
    {
      logger.Info(p);
    }
  }
  return m;
}

In this case, the purpose of the function is to compute a transformation matrix. So, after computing it, I log the matrix. I don't about you, but I would have a hard time telling if the matrix was really right or not. But, I would have a pretty idea if it is right be comparing some before and after views of some known test points. In the scheme of things, getting the test points and transforming them might be enough work that I just don't want to consider doing it unless I am logging, so I bracket the entire block with IsXXXEnabled.

I also agree that providing the delegate signatures via extension methods might be a good way to go. The one question I would have about that is whether or not the call site information will still work correctly. That is, will log4net and NLog be able to determine the calling method? I know that there is an issue with this right now for log4net and that there was an issue with NLog, but a fix has been checked in. If you essentially wrap the ILogger logging call in an extension method, does that break the call site preservation fix that has been made for NLog? I haven't checked myself, but I have a feeling that the Type parameter that is being passed to NLog.Logger.LogEvent will cause NLog to go up the stack until the frame after the frame containing that Type. That would be the stack frame of the extension method, not the "real" calling method.

New Post: callsite is lost through NLogFacade

wageoghe — Fri, 20 Aug 2010 19:52:13 GMT

You might already know this, but the log4net logger supports an ILogger interface (note that this is NOT the same as the log4net ILog interface). According to the documentation, ILogger.Log is the most generic way to log a message. It has two overloads, one of which takes a LoggerEvent class. LoggerEvent appears to be similar to NLog's LogEvent (which you apparently used to preserve the call site info for your NLog wrapper). Maybe you could use a similar approach to preserve log4net's call site info as you used to preserve NLog's. One field in LoggerEvent is LocationInfo. It looks like LocationInfo can get the location info automatically (which won't help if it is called from within SLF) OR it also has a constructor that accepts the class name, method name, filename, and line number which might be easier to obtain (class name and method name, anyway).

Another idea, maybe not a good one, is to use the approach that is used within the Logging Application Block.

Here is what LAB does in its logger (or did in the version that is available on koders.com):

private string GetCallingMethod()
        {
            string methodName = string.Empty;
            StackTrace trace = new StackTrace(true);
            foreach (StackFrame frame in trace.GetFrames())
            {
                // find the first method that isn't from this class
                if (!frame.GetMethod().ReflectedType.Equals(typeof(EntLibLogger)) &&
                    !frame.GetMethod().ReflectedType.Equals(typeof(ExceptionManager)))
                {
                    methodName = string.Format("{0} {1}:{2}",
                        frame.GetMethod().DeclaringType.ToString(),
                        frame.GetMethod().ToString(),
                        frame.GetFileLineNumber());
                    break;
                }
            }
            return methodName;
        }

Anyway, this class walks the stack up until the type of the MethodBase is not one of several Enterprise Library types.

Here is some experimental code that I wrote trying to mimic what is going on in LAB. I think that I got the "IsAssignableFrom" bit from StackOverflow, as I don't recall that LAB did this exactly the same way:

    internal string GetCallingMethodName()
    {
      string result = "unknown";
      StackTrace trace = new StackTrace(false);
      for (int i = 0; i < trace.FrameCount; i++)
      {
        StackFrame frame = trace.GetFrame(i);
        MethodBase method = frame.GetMethod();
        Type dt = method.DeclaringType;
        if (!typeof(ILogger).IsAssignableFrom(dt) && method.DeclaringType.Namespace != "DiagnosticsLibrary")
        {
          result = string.Concat(method.DeclaringType.FullName, ".", method.Name);
          break;
        }
      }
      return result;
    }

The idea is to walk the stack up until you hit a MethodBase that does not support ILogger and the MethodBase's namespace is not the "logging" namespace. In my case, this code was in a class that implements ILogger. If I had put the code in some other part of the logging infrastructure, then the IsAssignableFrom check is probably not good.

Obviously this is expensive to do on every logging call. Part of the problem is that, by default, log4net and NLog don't have to do this unless that is an element in the formatting string that specifies that the call site should be logged. So, at the time the message is logged (from application code directly to log4net or NLog), no extra cost is paid. The cost does not come until the message is actually formatted by log4net or NLog and written out. If the wrapper gets the call site info (as was done in the NLog wrapper/facade) then the cost of getting the information is paid during every logging call, whether or not the underlying logger's formatting string is going to use it. I guess that there is not much that can be done since it is probably difficult/impossible to tell when/if an underlying logger is going to need to call site info.

Having said all of that, see the answer by flanders in this post from StackOverflow for another way to get the calling method/class from an arbitrary depth in the calling stack:

http://stackoverflow.com/questions/171970/how-can-i-find-the-method-that-called-the-current-method

One way to save the cost of determining the call site info could be to have a configuration parameter in the "logging factory" config section (where you can specify the log4net or NLog facades) that says whether or not to get the call site info. So, if someone is using log4net and chooses not to configure call site info in any formatting strings, then he/she could turn the option off in the log4net facade config section. If the "GetCallSiteInfo" parameter is "true", then get the info, populate the LoggingEvent/LogEvent class/structure, and use the underlying logging platform's generic "Log" method. If "false", could still use the LoggingEvent/LogEvent and the generic "Log" method, but populate method and class with something like "[SLF CALL SITE LOGGING NOT CONFIGURED]" (or similar). Putting something like that for the method/class info would make it a bit more obvious if there was a conflict between asking for the call site info in log4net/NLog and NOT asking for it in SLF. Alternatively, SLF could log an informational message in its internal log about whether or not the call site parameter was set. In the actually logging call (SLF's call to log4net/NLog to log), if call site info is not specified, you might just want to use the "normal" way of calling log4net/NLog (logger.Info(blah blah) rather than logger.Log(new LogEvent(blah blah blah).

After typing all of that about getting the calling method info by walking the stack, I just looked at log4net some more and it looks like, maybe, the ILogger.Log function (remember, ILogger not ILog) supports a similar concept to NLog's Logger.Log( ... ), which you used to preserve call site info for NLog. Log4net's ILogger.Log call takes a Type parameter that, according to the docs, means this: "The declaring type of the method that is the stack boundary into the logging system for this call". Maybe it functions the same was as the Type passed to NLog's Logger.Log call? Maybe you have already looked at this and determined that it doesn't work the same way. Anyway, just thought I would pass it along.

Anyway. maybe you will find some of this useful, maybe not. I don't know yet if our project will use SLF, but I certainly think that it looks interesting.

New Post: Provide TraceSource Support in SLF Core

wageoghe — Fri, 20 Aug 2010 17:40:21 GMT

I am late to comment on this, but I have just started looking in detail at SLF. I think it is a good idea to provide a TraceSource support in SLF. The one additional suggestion that I would make is to consider support for hierarchical logger naming (maybe your existing hierarchical logger naming support elsewhere in SLF would be sufficient???). Castle provides a TraceSource-based logging facility (maybe facility is more of a NInject term, I don't can't remember) that supports hierarchical naming. In essence, if logger "ABC.123.xyz" is requested and there is not a TraceSource with that exact name (case insensitive) that was configured in the app.config file, then it backs up to "ABC.123", "ABC", and, finally "" until it finds a TraceSource that was configured. If it finds an ancestor, then the TraceSource with the requested name is configured to have the same properties (Switch, TraceListener(s)) as the ancestor. In other words, if "ABC" was configured in the app.config, then requestes for "ABC.123" and "ABC.123.xyz" would yield TraceSources with the same properties as the first-found parent.

If none are found, then a "Default" TraceSource is used. The way Castle checks to see if a TraceSource with the given name was configured in the app.config is to check the returned TraceSource's properties. If the returned TraceSource has exactly 1 TraceListener and that TraceListener is the DefaultTraceListener and the name is "Default", then a TraceSource with that name is assumed to have not been configured.

Castle also keeps a dictionary of all created TraceSources, checking the dictionary first for a TraceSource and then delegating to app.config (TraceSource ts = new TraceSource("xyz")) if they haven't already created that TraceSource.

So, with what you outlined above and with hierarchical naming support, you could write logging code like this:

// If TraceSource "Foo" is configured in app.config and the others are not, "Foo.Bar" and "Foo.Bar.What" will yield TraceSources configured identically to "Foo".
// If TraceSource "Foo" and "Foo.Bar.What" are configured in app.config and "Foo.Bar" is not, "Foo.Bar" will yield a TraceSource configured identically to "Foo".
// If TraceSource "Foo" and "Foo.Bar" are configured in app.config and "Foo.Bar.What" is not, "Foo.Bar.What" yield yield a TraceSource configured identically to "Foo.Bar".

var logger1 = LoggerService.GetLogger("Foo");
var logger2 = LoggerService.GetLogger("Foo.Bar");
var logger3 = LoggerService.GetLogger("Foo.Bar.What");

logger1.Warn("Hello from Foo");
logger2.Info("Hello from Foo.Bar");
logger3.Error("Hello from Foo.Bar.What");

You can see exactly what they did here:

http://github.com/castleproject/Castle.Core/blob/master/src/Castle.Core/Core/Logging/TraceLogger.cs

Note that I have not used Castle so I can't comment on how good or not this approach is from experience, but it looks like a pretty good approach.

I will also make a comment about formatting the log messages. There are extensions to System.Diagnostics (such as Ukadc.Diagnostics here on codeplex http://ukadcdiagnostics.codeplex.com/) that support formatting similar to how log4net and NLog support formatting (via a formatting string in the app.config file). For Ukadc.Diagnostics, the formatting support is implemented in the TraceListener. Formatting tokens are supported for the message, event id, time, timestamp, machine, thread, process, etc. Depending on what FormatItem (in the Log method) does to build the message string that is sent to TraceSource.TraceEvent, could there be a conflict with the formatting that will be applied later by Ukadc.Diagnostics? For example, if FormatItem adds the time so that "Hello World!" becomes "20-Aug-2010 12:32 pm, Hello World!", then when Ukadc.Diagnostics formats the message, it might apply the date/time (if specified in the formatting string), resulting in a message that might look like: "20-Aug-2010 12:32 pm, 20-Aug-2010 12:32 pm, Hello World!". I guess that FormatItem might not do anything, so "formatting" a message that has "Hello World!" might just return "Hello World!" and everything would be ok.

New Post: callsite is lost through NLogFacade

mfpinhal — Thu, 27 May 2010 13:43:03 GMT

Hey Colin, Any Idea about when will a new version be released? Regards, Mário

New Post: Factory for BitLaboratory (Object Guy's) Logging Framework?

qstarin — Thu, 06 May 2010 22:18:27 GMT

I decided to try this Logging Facade because it claimed support for BitLaboratory's Logging framework. However, and maybe a simple fact is escaping me, but it appears that the BitLaboratory facade adapter is missing a crucial piece - the Factory.

I am attempting to configure my logging declaratively in the config file, and as I look at the examples and the source code it appears this would not be possible without a factory.

I can see where the default Resolver after a reset on the LoggerService is the AppConfigFactoryResolver. I also see how this creates a dictionary of Factories keyed by the logger names, and how it matches the name argument to LoggerService.GetLogger(string name) to those logger keys in order to resolve and return a factory. Then the actual logger is created through a method call to the factory.

So, the way it appears to me, to the best of my understanding, is that I will have to create a Factory that delegates to BitLaboratory's Library's ConfigLogger.Instance.

Am I missing something? Something that allows me to configure SLF to use the BitLaboratory's Logging Framework, all configured declaratively through the app/web config's?

After looking a little closer, I do see this ability to configure BitLaboratory's Framework declaratively is a newer feature, and perhaps SLF simply hasn't been updated. As an aside, since this task is somewhat trivial, may I submit my Factory to be included in future releases of SLF? I would feel much better about using this facade for my company if this particular usage scenario was specifically supported by the official build of SLF.

New Post: callsite is lost through NLogFacade

ColinEber — Wed, 05 May 2010 07:21:31 GMT

Hi Mario,

No problem - if you have any more feedback, let me know. I think we will release a new version quite soon. We do not have many pending new features (we are keeping SLF simple!), so I will probably bundle this with just one or two other changes shortly.

Regards, Colin E.