Re: [Netcommon-developer] According to Request ID 2514434: Add LoggingMessage- and LogMessage-Event to LogManager

[Erich E. <eei...@gm...>]

Hi Jörg,

 

I agree w/ Mark here. Although I enjoyed kicking him *bg*

 

Common.Logging is especially designed to be slim and fast. It even makes
sense to use Common.Logging in the case you never intend to switch your
target logging system because of a) reduced performance costs and b) a new
logging feature leveraging lambda expression to help you avoid sideeffects.
I recently published a blog post with my performance test results
(http://eeichinger.blogspot.com/2009/01/thoughts-on-systemdiagnostics-trace-
vs.html).

 

Having said that, introducing an event that gets fired every time a message
is logged is not within the responsibilities the framework is designed for.
But, as Mark mentioned, you can always write a FactoryAdapter decorator,
that hands out decorated ILog instances to intercept logging calls. You
don't even need AOP for this, it is quite straight forward to handcode such
a decorator yourself.

 

let me know if I can be of any help!

 

cheers,

Erich

 

From: Mark Pollack [mailto:Mar...@sp...] 
Sent: Samstag, 24. Jänner 2009 18:20
To: Jörg Metzler; net...@li...
Subject: Re: [Netcommon-developer] According to Request ID 2514434: Add
LoggingMessage- and LogMessage-Event to LogManager

 

Hi,

 

At first glance, I’m not very keen to add this feature, but I’d like to hear
others opinions. The goal of this project is portable logging and this
sounds like a new top level feature, unique to common logging, so I’d vote
-1.  I was pulled kicking and screaming to add string format support to the
API in 2.0 just to put it in perspective.

 

As I’m sure you know, logging implementations usually take care of by
providing a plug-in point via logging adapters for the database, messaging,
etc.   This is a provider specific solution, but that would be the way to go
if you want to accurately tie into the underlying logging trail.  The
logging subsystem is actually responsible for creating the final log output
– which usually gets stuff appended to the ‘base string’ that is set as a
user – for example nested diagnostic context in log4net.  If the requirement
here is essentially a log viewer/analyzer, that seem natural, if it is more
business focused, I’d treat it as a first class problem to be solved via
some oo-design and not to piggy-back on top of the logger infrastructure.
The ‘third way’ would be to create your own LogManager that returns ILog
instances wrapped in an AOP proxy.  Then you can apply whatever behavior you
like to the ILog interface methods.

 

Cheers,

Mark

 

 

From: Jörg Metzler [mailto:joe...@we...] 
Sent: Saturday, January 24, 2009 5:30 AM
To: net...@li...
Subject: [Netcommon-developer] According to Request ID 2514434: Add
LoggingMessage- and LogMessage-Event to LogManager

 

 

 

Von: Jörg Metzler [mailto:joe...@we...] 
Gesendet: Dienstag, 20. Januar 2009 22:04
An: 'net...@li...'
Betreff: According to Request ID 2514434: Add LoggingMessage- and
LogMessage-Event to LogManager

 

Hello,

 

I just downloaded the code for Common.Logging and modified it a bit.

 

I added an event that is fired, everytime a log-method is called.

Why? 

I want to show some of the log message in a WindowsForms ListBox or
something like that. One possibility was to create a super uber special
ILoggerFactoryAdapter and cast the LogManager.Adapter to this in my
application. This sucks and is the root of all evil, because I can’t change
the implementation. Additionally the implementation of the logging should
not influence my app.

 

So what’s new?

The LogManager has two new Properties:

-        LogMessage (event) 

New Files:

-        LogMessageEventArgs.cs

-        Internal\InternalLog.cs

-        Internal\InternalLoggerFactoryAdapter.cs

-        Internal\LogMessageCallback.cs

-        Internal\NeedsCallLogMessageCallback.cs

 

Could you add this in your next release or is it bullshit what I coded? :-)

 

Please let me know.

 

 

Jörg Metzler