[ http://issues.apache.org/jira/browse/LOG4NET-2?page=all ]
Nicko Cadell updated LOG4NET-2:
---
Fix Version: v.Next
Description:
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
was:
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
> 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
> Fix For: v.Next
>
> 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 doe
