One of the benefits of having AppSetting values settable within the log4net.config file is that you can make changes to how log4net works without having to re-cycle your application. Having said that, I doubt there is a high demand for setting then resetting log4net.Internal.Quiet without re-cycling the application.
Could you give some examples of why having multiple log4net nodes in a single config file would be beneficial? Would it be for something like this: <log4net name="DEBUG" /> ... </log4net> <log4net name="RELEASE" /> ... </log4net> This may be useful too: <log4net name="localhost" /> ... </log4net> <log4net name="remote.server.com" /> ... </log4net> Can't I accomplish that functionality today by naming files a certain way? log4net-DEBUG.config log4net-RELEASE.config log4net-localhost.config log4net-remote.server.com.config I'm sure there are reasons to have multiple repositories...I've never been able to think of any. What about having a dedicated repository just for logging audit messages? --- Nicko Cadell <[EMAIL PROTECTED]> wrote: > I'm not too sure that the <log4net> node in the configuration should > be > used to set the log4net.Internal.Debug or log4net.Internal.Quiet > flags. > These are global flags and currently setting <log4net debug="true"> > will > turn on this global flag, but this is usually "too late". If the user > want to enable internal debug then it is best to set it using the > AppSetting. That is the only way to ensure that log4net writes out > all > the version, and system configuration info and the search strategy > for > the config file. > > In future we may support multiple <log4net> nodes in a config file to > support simple configuring of multiple repositories. Each repository > is > isolated and in general I would prefer not to have the configuration > for > a specific repository modifying our global state. > > I don't mean that we should remove support for the <log4net > debug="true"> setting, but rather than setting the global value it > should be scoped to the repository, and preferably only to this > configuration of the repository. This is not simple with the current > implementation, but we can implement something to do this once we > decide > how to resolve LOG4NET-2 (Configurator should report errors). I have > some ideas on how to do that but they would involve breaking API > changes > for anyone configuring log4net programmatically (not just calling > XmlConfigurator.Configure, but actually creating the Appenders and > Loggers programmatically). I will outline these ideas soon, I'm not > sure > how much pain this would cause our users. > > Cheers, > Nicko > > > -----Original Message----- > > From: Ron Grabowski (JIRA) [mailto:[EMAIL PROTECTED] > > Sent: 04 November 2005 02:16 > > To: [email protected] > > Subject: [jira] Created: (LOG4NET-54) Ensure all AppSettings > > settings are settable on XmlHierarchyConfigurator's log4net node > > > > Ensure all AppSettings settings are settable on > > XmlHierarchyConfigurator's log4net node > > -------------------------------------------------------------- > > ------------------------- > > > > Key: LOG4NET-54 > > URL: http://issues.apache.org/jira/browse/LOG4NET-54 > > Project: Log4net > > Type: Improvement > > Reporter: Ron Grabowski > > Priority: Minor > > > > > > The "log4net.Internal.Debug" AppSetting key can be setup on > > the log4net node using the "debug" attribute. > > "log4net.Internal.Quiet" is settable via AppSettings but not > > on the log4net node. > > > > -- > > 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 > > - > > For more information on JIRA, see: > > http://www.atlassian.com/software/jira > > > > >
