logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicko Cadell" <ni...@neoworks.com>
Subject RE: [jira] Created: (LOG4NET-54) Ensure all AppSettings settings are settable on XmlHierarchyConfigurator's log4net node
Date Fri, 04 Nov 2005 15:15:28 GMT
It's unusual to configure log4net with multiple repositories, but the
architecture (inherited from log4j) is designed to support this. The
simplest way to create multiple repositories to specify the
RepositoryAttribute on an assembly. This would allow users to assign a
different repository to different assemblies in your application. This
may be something that library developers would like to do so that their
log messages are isolated from the main application. The library's
logging could be configured using a separate config file, or the
application could choose to merge the libraries repository into the
default repository (using the AliasRepositoryAttribute).

When we configure a repository using XML data the XmlConfigurator
selects the first <log4net> element in the XML. We could change this to
look for <log4net name="repository-name">. This would allow users to
have a single configuration file for multiple repositories.

If log4net is updated to use log4net for internal logging (as log4j
does) then it is likely that this will go out into a separate
repository. Most of the time users won't want to see log4net internal
messages, and we don't want to make then have to write <logger
name="log4net"><level name="ERROR" /></logger> in every config file. The
same holds true for other 3rd party libraries that use log4net.

Nicko

> -----Original Message-----
> From: Ron Grabowski [mailto:rongrabowski@yahoo.com] 
> Sent: 04 November 2005 14:50
> To: Log4NET Dev
> Subject: RE: [jira] Created: (LOG4NET-54) Ensure all 
> AppSettings settings are settable on 
> XmlHierarchyConfigurator's log4net node
> 
> 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 <nicko@neoworks.com> 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:jira@apache.org]
> > > Sent: 04 November 2005 02:16
> > > To: log4net-dev@logging.apache.org
> > > 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
> > > 
> > > 
> > 
> 
> 

Mime
View raw message