Andrey, Thanks for your help. We will have some form of support for WMI in the next version of log4net. http://issues.apache.org/jira/browse/LOG4NET-51
Nicko > -----Original Message----- > From: Andrej Golcov [mailto:[EMAIL PROTECTED] > Sent: 10 November 2005 11:22 > To: Log4NET Dev > Subject: RE: WMI Appender > > > Nicko, > > I changed files you sent me to avoid need to register > WmiAppender by InstallUtil. Mailing of zip files is banned, I > can send you files directly or add into SVN. > > The main idea I want to illustrate 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 assembly. > > SampleWmiLayout - contains WmiLayout.cs and > WmiLoggingEvent.cs, 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 - contains ApplicationWmiEvent.cs, implements > a custom WMI event (ApplicationSpecificEvent) used directly > from the application > > WmiAppenderApp - contains Class1.cs and Test.cs, demonstrates > both use cases: > - Logging a string with triggering WmiLoggingEvent by > SampleWmiLayout.WmiLayout > - Direct logging a WMI event (ApplicationSpecificEvent) from > an application > > Regards, Andrej > > > -----Original Message----- > From: Nicko Cadell [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 23, 2005 12:44 PM > To: Log4NET Dev > Subject: RE: WMI Appender > > 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 > > > > > > >
