[
https://issues.apache.org/jira/browse/LOG4NET-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515131
]
Curt Arnold commented on LOG4NET-2:
-----------------------------------
This one also affects log4j and logcxx (and likely log4php). log4j 2.0 will
likely revisit the whole configuration space and one possible approach is to
collaborate on a common redesign and then push it to all the frameworks. On a
tangental issue, I did some exploratory work on a strictxml configuration
dialect (where a validating parser or XML editor would be much more likely to
identify configuration errors) a few years ago in the sandbox.
My thinking on log4j 2.0 is to first design for configuration by Java
Management Extension (JMX) and then an existing configuration framework (there
are a couple already in ASF). Support for the existing log4j configuration
formats could be provided by XSLT transforming the configuration files into the
"new" configuration language and then having the existing framework process it.
configurationAndWatch is addictive but problematic and a JMX approach for
run-time modification of configuration would be much cleaner.
> Configurator should report errors
> ---------------------------------
>
> Key: LOG4NET-2
> URL: https://issues.apache.org/jira/browse/LOG4NET-2
> Project: Log4net
> Issue Type: Improvement
> Components: Core
> Affects 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 does not seem to
> be a simple way to diagnose the problem.
> Ben Newman - benjamin91
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
