[ http://issues.apache.org/jira/browse/LOG4NET-2?page=comments#action_59898 ] Nicko Cadell commented on LOG4NET-2: ------------------------------------
The configure and watch functionality means that the logging configuration file may be reloaded at any time (i.e. when the file system watcher thinks the file has changed). As this could generate configuration errors, and it happens on a worker thread that the calling application does not know about it does not seem possible to reliably throw exceptions for configuration errors. Therefore it would seem better to store the configuration errors on the LoggerRepository and retrieve them after configuration. An even is raised after configuration is reloaded, this could be used as a hook to verify the configuration error status. As a usability tweak the configurator methods could be enhanced to return an object containing the configuration errors. > Configurator should report errors > --------------------------------- > > Key: LOG4NET-2 > URL: http://issues.apache.org/jira/browse/LOG4NET-2 > Project: Log4net > Type: Improvement > Components: Core > Versions: 1.2.9 > Environment: From sourceforege - Tor Hovland - torhovl > Reporter: Nicko Cadell > > I understand that you do not want to throw exceptions > from within the logging methods, as a failure in log4net > would make the hosting app fail. > However, I think it is necessary that DOMConfigurator > throws exceptions. If a failure occurs at that point, for > example due to a malformed configuration file, I believe > the hosting app would in most cases like to know. Even > if it doesn't, it could easily just swallow any exceptions. > In my case, I have a Windows Service app that will just > quit logging if there is an error in the configuration file. > That makes the logging mechanism rather more fragile > than I would like. > Tor Hovland - torhovl > --- > I completely agree. I suggest that you take an additional > step and provide an additional mechanism, perhaps a > ValidateLoggers() method which operates like a standard > logging call, but is capable of throwing exceptions or > providing another form of feedback which would allow the > caller to diagnose bad configurations. The configuration > file can be well-formed, but logging can still fail for any > number of reasons. > Most applications that provide a logging mechanism employ a > 'start-up banner' log entry at an INFO level. This would be > a great time to detect any problems with the logging system > itself. I currently have a project deployed at a customer > site and despite a well formed config file... no logging is > taking place. I don't know why, and there does not seem to > be a simple way to diagnose the problem. > Ben Newman - benjamin91 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
