slf Issue Tracker Rss Feed

Commented Issue: Create NuGet package for SLF [31452]

ipashchuk — Wed, 14 Sep 2011 18:15:03 GMT

Would be great to have a NuGet package so that the SLF.dll wouldn't have to be embedded in libraries that are distributed as NuGet packages.
Comments: ** Comment from web user: ipashchuk **

I'm attaching a NuGet package for SLF Core. I would be happy to upload it to the official NuGet repository if you guys are busy.

Commented Issue: Create NuGet package for SLF [31452]

ipashchuk — Tue, 13 Sep 2011 14:08:58 GMT

Would be great to have a NuGet package so that the SLF.dll wouldn't have to be embedded in libraries that are distributed as NuGet packages.
Comments: ** Comment from web user: ipashchuk **

It would probably be best to create NuGet packages as follows:
- SimpleLoggingFacade.Core (just the SLF binary)
- SimpleLoggingFacade.Log4Net
- SimpleLoggingFacade.NLog
- SimpleLoggingFacade.EntLibLogging
- SimpleLoggingFacade.BitFactory

Created Issue: Create NuGet package for SLF [31452]

ipashchuk — Tue, 13 Sep 2011 13:59:54 GMT

Would be great to have a NuGet package so that the SLF.dll wouldn't have to be embedded in libraries that are distributed as NuGet packages.

Commented Task: Explore the impact of SLF on nlog / log4net stacktraces [25524]

wageoghe — Fri, 10 Sep 2010 18:31:18 GMT

Both NLog and log4net have formatters that output information relating to the call-stack. Currently SLF will obscure this.

What can we do?

The only solution I can thin of, which is a bit nasty, is to create our own builds of NLog and log4net that skip stack frames.
Comments: ** Comment from web user: wageoghe **

I have added a comment in the "callsite is lost through the NLogFacade" discussion thread about how to fix this problem for log4net. You can look there for more info, or I will also include some sample code here:

/// <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);
}

By using the log4net logger's "Log" method and passing the type of the wrapping logger, log4net knows which DeclaringType in the call stack is the entry point for the logging call. One step up from that should be in the actual user code.

Commented Feature: Add IsWarnLevelEnabled, IsInfoLevelEnabled ... properties [25523]

phsumi — Thu, 03 Dec 2009 17:21:42 GMT

Add IsWarnLevelEnabled ... properties to ILogger.

First double check the log4net / NLog APIs, I believe they both use the same property names, so we should do the same.

(Philipp, are you happy with this one?)

Created Task: Explore the impact of SLF on nlog / log4net stacktraces [25524]

ColinEber — Thu, 03 Dec 2009 17:18:15 GMT

Created Feature: Add IsWarnLevelEnabled, IsInfoLevelEnabled ... properties [25523]

ColinEber — Thu, 03 Dec 2009 16:58:11 GMT

Closed Task: SL Sample - Logging via WCF [25433]

phsumi — Wed, 02 Dec 2009 16:33:01 GMT

Create a Silverlight sample that shows logging to the server via a WCF façade.

Closed Task: SL Sample - Log to Browser Console [25434]

phsumi — Wed, 25 Nov 2009 11:31:36 GMT

Create a simple sample that shows how to log to the browser console in SL applications through SLDebugLogger.

Created Task: SL Sample - Log to Browser Console [25434]

phsumi — Mon, 23 Nov 2009 11:25:21 GMT

Create a simple sample that shows how to log to the browser console in SL applications through SLDebugLogger.

Created Task: SL Sample - Logging via WCF [25433]

phsumi — Mon, 23 Nov 2009 11:06:33 GMT

Create a Silverlight sample that shows logging to the server via a WCF façade.

Created Feature: Should we add Filtering Support to SLF? [25432]

phsumi — Mon, 23 Nov 2009 10:56:58 GMT

Filtering is currently not part of SLF - we rely on the individual filtering capabilities of the underlying frameworks and their configuration.

We should evaluate whether to include filtering directly in SLF for the following reasons:
- Filtering in SLF would be a truly generic mechanism that promotes SLF's seamless switching capabilities between logging frameworks.
- Filtering is a *very* fundamental concept - including it in SLF makes it available for simple loggers or custom logging strategies that don't need to provide their own filtering.
- Filtering in certain frameworks is quite complex - providing it in SLF makes it very easy.
- Filtering is an optional feature. One can always use proprietary filtering mechanism of the given logging frameworks.

Suggested implementation: Filtering should be directly enabled via LoggerService, in order to keep things simple. Again, we should provide a pluggable mechanism (ILogFilter interface) which allows us to rely on app.config, or just plug in custom filtering at runtime:

//plug in a global filter at runtime
LoggerService.Filter = new LogLevelFilter(LogLevel.Fatal, LogLevel.Error, LogLevel.Warn);

Cons:
- SLF receives an additional aspect, which might contradict the idea of a thin façade to logging frameworks.
- Filtering can be seen as the responsibility of the underlying logging framework, not SLF.
- other?

Please discuss!

Closed Task: Extend and Refactor LogItem [22497]

phsumi — Mon, 23 Nov 2009 10:44:19 GMT

LogItem is a legacy class - should be refactored and probably renamed (LogMessage?).

Closed Task: Add Message Formatting Capabilities [22498]

phsumi — Wed, 07 Oct 2009 09:13:42 GMT

Allow users to format parameterized strings on the fly:

ILogger logger = GetLogger();
logger.Log("Result of {0} is {1}", term, result);

...one could also think of a more fluent interface.
Comments:

Closed Issue: Which .NET version? Which SL version? [23072]

phsumi — Wed, 07 Oct 2009 09:13:10 GMT

Currently the SLF core is built for .NET 3.5, however the only .NET3.5 feature used in the ToList() extension within CompositeLogger. Perhaps SLF core should be built for .NET 2.0.

Also, SLF.Silverlight is built for SL 3.0, perhaps SL 2.0 would be a better choice?
Comments:

Closed Task: Codestyle? formatting? [23076]

phsumi — Wed, 07 Oct 2009 09:12:59 GMT

Hi Philipp, I can see that you use 2 spaces = 1 tab.

Perhaps we need a simple style guide - possibly just a standard one which can be referenced?
Comments:

Commented Task: Extend and Refactor LogItem

ColinE — Thu, 27 Aug 2009 09:38:52 GMT

LogItem is a legacy class - should be refactored and probably renamed (LogMessage?).
Comments: ** Comment from web user: ColinE **

One quick thought ... for exceptions we are throwing away some important information such as the stack trace.

Commented Issue: Which .NET version? Which SL version?

phsumi — Mon, 15 Jun 2009 17:10:06 GMT

I just created the SL project in order for it be there, but felt that this one should be your playground anyway. SL 2.0 makes definitely sense.

Regarding the used .NET framework: This hurts - I really love my LINQ. But I switched to 2.0. You owe me one for this ;)

Created Issue: Codestyle? formatting?

ColinEber — Mon, 15 Jun 2009 10:56:45 GMT

Hi Philipp, I can see that you use 2 spaces = 1 tab - do you have a preferred style guide?

Created Issue: Which .NET version? Which SL version?

ColinEber — Mon, 15 Jun 2009 09:36:11 GMT