[ http://issues.apache.org/jira/browse/LOG4NET-33?page=all ]

patrick conant updated LOG4NET-33:
----------------------------------

    Attachment: DefaultRepositorySelector.cs.diff.txt

Here's another stab at enabling an appSettings property to confingure log4net.  
The new approach uses the DefaultRepositorySelector to configure only the 
default repository.  This still has the XmlConfigurator hard-coded.

> Ability to use global property to point to log4net configuration file
> ---------------------------------------------------------------------
>
>          Key: LOG4NET-33
>          URL: http://issues.apache.org/jira/browse/LOG4NET-33
>      Project: Log4net
>         Type: Improvement
>   Components: Core
>     Versions: 1.2.9
>  Environment: Any
>     Reporter: patrick conant
>     Priority: Minor
>  Attachments: DefaultRepositorySelector.cs.diff.txt, LogManager.cs.diff.txt, 
> configuration.xml.diff.txt
>
> The log4j tool has the ability to specify a system property to point to the 
> logging configuration file.  For instance, when starting a java program (such 
> as tomcat), one can pass "-Dlog4j.configuration=http://mydomain/log4j.xml"; as 
> a command line parameter.  Log4j checks to see whether this property is 
> available and, if it is, uses the return value from the URL to configure 
> categories and appenders.
> A similar mechanism in log4net would allow a few improvements in logging 
> configuring:
> * No need to use the XmlConfiguratorAttribute in any assemblies
> * No need to know at design time where the log4net config file will be located
> * Ability to configure logging for all components in an app domain by setting 
> a property in the app domain's config file
> * Ability to configure logging for all components on a machine by setting a 
> property in the machine.config file
> * Ability to updating config file contents without updating app or machine 
> config contents.
> I'd propose doing a direct mirror of the log4j capabilities into log4net as 
> follows:
> * Update the LogManager class with a static constructor that mirrors the 
> static block in the LogManager class in log4j
> * Use System.Configuration.ConfigurationSettings.AppSettings.Get(...) instead 
> of java's System.getProperty(...)
> * Don't support the configuratorClass attribute (yet) because the 
> XmlConfigurator seems to be the only logical choice
> * Don't implement the DEFAULT_XML_CONFIGURATION_FILE or 
> DEFAULT_CONFIGURATION_FILE property checks (yet). 

-- 
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

Reply via email to