logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrej Golcov <andrej.gol...@hermes.si>
Subject FW: WMI Appender
Date Thu, 10 Nov 2005 11:07:45 GMT

Please look into attached archive file. I little bit changed files you sent
me to avoid need to register WmiAppender by InstallUtil. 
The main idea I want to show is possibility to send WMI events directly from
an application with simultaneous possibility to trigger WMI events by
non-WMI logging such as usual string logging.

It is only proof of concept with no error handling, optimization, nant etc.

The solution contains four projects:

WmiAppender - a log4net appender accepts IRawLayout as layout. In DoAppend
method it calls layout.Format and than sends received from layout object
into the WMI. Does not require registration, but references
System.Management.Instrumentation. Can be added in log4net.dll.

SampleWmiLayout - can be changed for specific application but also can be
used as it is. Implements a simple layout that checks if
loggingEvent.MessageObject is WMI event 
if yes - return it 
if no - create and return a new WMI event WmiLoggingEvent

CustomWmiEvent - implements a custom WMI event (ApplicationSpecificEvent)
used directly from the application

WmiAppenderApp - demonstrates both use cases:
 - Logging a string with triggering WmiLoggingEvent by
 - Direct logging a WMI event (ApplicationSpecificEvent) from an application

Regards, Andrej

-----Original Message-----
From: Nicko Cadell [mailto:nicko@neoworks.com] 
Sent: Sunday, October 23, 2005 12:44 PM
To: Log4NET Dev
Subject: RE: WMI Appender


A WmiAppender is something that we want to support in log4net. I think
we will need to ship this as a separate assembly, and it may start out
life as a sample appender.

Attached is some sample code that should be a good starting point. It
has a WmiLayout that is responsible for turning the LoggingEvent into an
IEvent. You can subclass this and supply your own behaviour by setting
the <layout type="MyWmiLayout,MyAssembly" /> in the configuration for
the appender. By default the WmiLayout will check if the MessageObject
is an IEvent (if it also implements IWmiBoundEvent then it gets a chance
to extract data from the LoggingEvent) then that is returned, otherwise
it creates a WmiLoggingEvent with some of the data from the

So there are 3 supported customisation points:
  Log an IEvent as the log message object
  Log an IWmiBoundEvent as the log message object
  Subclass the WmiLayout to extract the relevant data from the

This code is missing the [assembly:Instrumented("")] attribute and any
installers to register the WmiLoggingEvent.

Let me know how you get on with this and please post back your
improvements (of which I'm sure there will be many :)


> -----Original Message-----
> From: Andrej Golcov [mailto:andrej.golcov@hermes.si] 
> Sent: 18 October 2005 09:31
> To: Log4NET Dev
> Subject: RE: WMI Appender
> I'd like to reestablish conversation about WMI appender. 
> MS claims WMI events as an important part of monitoring 
> solution, for example, see Monitoring in .NET Distributed 
> Application Design. So, the possibility to raise WMI events 
> is one of the key monitoring features for enterprise 
> applications. WMI events are natively built in LIAB from MS 
> Enterprise Library.
> WMI event trigger mechanism used in WMI appender must be 
> compatible with mechanism used in 
> System.Management.Instrumentation. Otherwise, it will be more 
> difficult for developers to register and develop custom WMI events.
> Have you thought about the following log4net WMI appender 
> functionality: 
> Introduce a new interface, like: 
> IWmiLoader
> { 
>         void Init(object LoggingEvent); 
>         void Fire();
> } 
> If LoggingEvent.MessageObject is not derived from 
> System.Management.Instrumentation.BaseEvent
> then get an assembly and class type from WMI appender 
> configuration setting. This class must implement IWmiLoader 
> interface. The WMI Appender initiates the class using 
> LoggingEvent and triggers Fire method.
> If LoggingEvent.MessageObject is derived from 
> System.Management.Instrumentation.BaseEvent
> then just trigger the fire method. If you do not want to have 
> dependency on System.Management.Instrumentation namespace, 
> you can check for IWmiLoader interface instead of 
> System.Management.Instrumentation.BaseEvent.
> In such case, WMI appender has no WMI events inside and does 
> not need to be registered using installutil. Log4net may 
> provide an example WMI event to be used in appender. 
> Developers will usually customize the example WMI event to 
> set application specific WMI namespace.
> Alternative option is to inherit LoggingEvent from 
> System.Management.Instrumentation.BaseEvent, like it is 
> implemented in LIAB. But I think it is not an issue in such 
> multiplatform project as log4net.
> Currently, we are about implementing WMI appender inside the 
> company, but I want to check with you to avoid double work 
> when/if WMI appender will be released in log4net. Is the 
> log4net community interested in our contributing to WMI 
> appender development?
> Thanks, Andrej 

View raw message