The static constructor on LogManager calls ShutDown in the AppDomain's
ProcessExit and DomainUnload:
// ProcessExit seems to be fired if we are part of the default domain
AppDomain.CurrentDomain.ProcessExit += new EventHandler(OnProcessExit);
// Otherwise DomainUnload is fired
AppDomain.CurrentDomain.DomainUnload += new EventHandler(OnDomainUnload);
----- Original Message ----
From: Michael Mayne <mich...@michaelmayne.me.uk>
To: Log4NET Dev <log4net-dev@logging.apache.org>
Sent: Tuesday, February 10, 2009 12:43:42 AM
Subject: RE: Appender Close() not being called when application ends
Hi,
It would be great if someone - anyone - could give me some feedback on this.
Perhaps it's a bug that log4net doesn't appear to close loggers before it is
garbage collected?
Thanks
Michael
Mailing list archives
Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Mayne <mich...@michaelmayne.me.uk>
Subject Appender Close() not being called when application ends
Date Fri, 06 Feb 2009 09:50:56 GMT
Hi,
I'm creating a custom AsyncAppender() that buffers synchronous event appends
, using an internal dequeue thread to process these buffered events sending
them onto attached appenders. The internal workings are not important to my
problem (I think)...
What I'm seeing is that neither the Close() or ~AsyncAppender() (finalize)
methods are being called when my test program attempts to exit i.e. my test
program hangs. This is important because my class cleanup triggers the
dequeue thread to drain any buffered events, terminate the thread and
dispose. If not triggered the dequeue thread sits there waiting on an
autoReset event for ever - hence the program hang.
However, If I explicitly shutdown the repository, Close() is called and it
all works perfectly.
logger.Logger.Repository.Shutdown();
AsyncAppender inherits AppenderSkeleton so overrides OnClose(). It also
implements IDisposable using the classic Dispose pattern.
My test program is configuring everything programmatically (no config files)
so I can see what's going on - well that was the idea J
I would have thought that when my program exited, Log4net would be garbage
collected and my Close() (or destructor) method would be called.
What am I doing wrong?
I can include some code later but I really want to get an idea of the
appender lifecycle.
Thanks
Michael
Mime Unnamed multipart/alternative (inline, None, 0 bytes)
Unnamed text/plain (inline, 7-Bit, 1380 bytes)
Unnamed text/html (inline, Quoted Printable, 4099 bytes)
View raw message
-----Original Message-----
From: Lukasz Antoniak (JIRA) [mailto:j...@apache.org]
Sent: 09 February 2009 23:52
To: log4net-dev@logging.apache.org
Subject: [jira] Commented: (LOG4NET-194) FileSystemWatcher for .Net Compact
Framework
[
https://issues.apache.org/jira/browse/LOG4NET-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672064#action_12672064
]
Lukasz Antoniak commented on LOG4NET-194:
-----------------------------------------
Welcome again!
I have spent some time developing FileSystemWatcher class, and I wanted to
share my results. In the attachment I submit several things:
1) Classes that I have modified or added (XmlConfigurator.cs,
FileSystemWatcher.cs, FileSystemEventArgs.cs and RenamedEventArgs).
2) The compiled assembly (debug).
3) The whole Log4Net project (for MS Visual 2008). I have added classes
mentioned above to Util/FileSystemWatcher folder.
4) The simple test case project. The test works as follows: When the
application starts, the new Log4Net configuration file is being created and 2
messages logged. The form provides two buttons. The first one "Log" logs
messages, and the second "Change" modifies the configuration file, so that the
log messages are saved to a different location (look in the application
directory in "Program Files" folder).
Is there any possibility to add those changes in next Log4Net release?
Regards,
Lukasz Antoniak
> FileSystemWatcher for .Net Compact Framework
> --------------------------------------------
>
> Key: LOG4NET-194
> URL: https://issues.apache.org/jira/browse/LOG4NET-194
> Project: Log4net
> Issue Type: Improvement
> Components: Other
> Affects Versions: 1.2.10
> Environment: .Net Compact Framework 1.0/2.0/3.5
> Reporter: Lukasz Antoniak
> Priority: Minor
> Attachments: log4netcf.vs2008.dll, log4netcf.vs2008_20090210.zip,
> Log4NetTest_20090210.zip, Modified_Files_20090210.zip
>
>
> Welcome!
> I would like to suggest an improvement of Log4Net utility for .Net Compact
> Framework. The .Net CF 1.0/2.0/3.5 does not provide developers with
> FileSystemWatcher class. However there is nothing against implementing a
> simple class invoking SHChangeNotifyRegister API in Log4Net. I have recently
> started developing mobile applications and I regret lack of automatic
> reconfiguration feature in Log4Net .Net CF. I am quite familiar with
> SHChangeNotifyRegister API and I could try to modify XmlConfigurator class to
> support configuration file monitoring. What do you think of this idea?
> If there was an opportunity, I would like to contribute to Log4Net project.
> Regards,
> Lukasz Antoniak
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.233 / Virus Database: 270.10.19/1940 - Release Date: 02/08/09
17:57:00
