Andrej, 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
LoggingEvent.
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
LoggingEvent
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 :)
Cheers,
Nicko
> -----Original Message-----
> From: Andrej Golcov [mailto:[EMAIL PROTECTED]
> 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
>
>
WmiAppender.cs
Description: WmiAppender.cs
WmiLayout.cs
Description: WmiLayout.cs
WmiLoggingEvent.cs
Description: WmiLoggingEvent.cs
IWmiBoundEvent.cs
Description: IWmiBoundEvent.cs
