logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicko Cadell" <ni...@neoworks.com>
Subject RE: WMI Appender
Date Fri, 18 Nov 2005 10:37:40 GMT
 

> From: Andrej Golcov [mailto:andrej.golcov@hermes.si] 
> 
> I've check the SVN repository for WMI Appender. 
> Current approach has one problem, at least for us. 
> WMI evet type is hardcoded in appender. It is impossible to 
> log WMI events directly from the application. 

If the loggingEvent.MessageObject is an IEvent then that object will be
fired, this allows the app to log their own WMI compatible objects.
System.Management.Instrumentation.IEvent is the marker interface that
identifies the type as a WMI Event, this is equivalent to
InstrumentationClassAttribute but the test for it is more performant and
it is typesafe.

If the app wants to generate their own custom WMI event for all log
messages then they just need to subclass the WmiLayout and override the
CreateEvent method to return their own WMI IEvent object. They need to
specify their WmiLayout subclass in the configuration for the
WmiAppender.

So apart from not supporting custom application WMI events that are
identified by the InstrumentationClassAttribute rather than by the
IEvent interface I think this should do everything you need.

Cheers,
Nicko


> 
> Regards, Andrej 
> 
> -----Original Message-----
> From: Nicko Cadell [mailto:nicko@neoworks.com]
> Sent: Sunday, November 13, 2005 8:31 PM
> To: Log4NET Dev
> Subject: RE: WMI Appender 
> 
> 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:andrej.golcov@hermes.si]
> > 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:nicko@neoworks.com]
> > 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: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
> > > 
> > > 
> > 
> >   
> > 
> 
> 

Mime
View raw message