|
From: Erich E. <eei...@gm...> - 2009-01-29 09:20:05
|
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, Im not very keen to add this feature, but Id 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 Id 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 Im 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, Id 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 cant change the implementation. Additionally the implementation of the logging should not influence my app. So whats 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 |