Patrick, Thanks for the patch, I have a few comments on the best approach below.
log4j has a very much simpler default RepositorySelector than log4net. It is the log4net DefaultRepositorySelector that looks for the attributes defined on the calling assembly for repository and configuration settings. The behaviour under log4j is that the default repository is configured using the config property. There can only be one repository instance because the log4j default RepositorySelector restricts you to one and only one. If a different RepositorySelector is specified then the default repository may change depending on the implementation of the selector. In log4net the LoggerManager does not create a default repository, but delegates this to the selector. Calling XmlConfigurator.Configure(string) from within the log4net assembly will not necessarily have the expected behaviour, as it is asking to configure logging for the log4net assembly. I would rather put the code for this in the RepositorySelectors themselves as they know more about the number, structure and relationship between the repositories. For example if the DefaultRepositorySelector creates more than one repository should they all be configured using the appSettings config file, or should it just be the first one, or the default one? What should happen if the assembly has XmlConfiguratorAttributes defined? Should both sets of config be loaded, or should one take priority? I think that there is an argument to say that the config file specified in the appSettings should override the config attribute because the config attribute is set at compile time, and the appSettings value can be updated at deployment time. However it may not be appropriate to override the attributes for all the logger repositories that are configured, I think that it should just be for the default repository. This can be implemented in the DefaultRepositorySelector.ConfigureRepository method by checking the repository Name property for the DefaultRepositoryName and only then loading the config file the appSettings specified config file. Preferably I would like to see some mechanism that supports different configurators rather than just hard coding it to the XmlConfigurator, although that may be the default behaviour. As the .NET Compact Framework does not support appSettings there is no need to update the CompactRepositorySelector. As an aside you seem to have generated your patches backwards, i.e. how to undo your changes, not really a big problem as they can be applied backwards too. Cheers, Nicko > -----Original Message----- > From: Conant, Patrick D [mailto:[EMAIL PROTECTED] > Sent: 06 June 2005 18:51 > To: Log4NET Dev > Subject: RE: System-wide configuration for log4net > > After playing around more, it becomes clear to me that the > XmlConfigurator won't even get instantiated if the > XmlConfiguratorAttribute (or some other attribute class) isn't used. > Delving into the log4j codebase, Log4j looks for the > "log4j.configuration" parameter in a static block in the > LogManager class -- thus ensuring that the > "log4j.configuration" parameter is used event when no > Configurator is ever explicitly called by the logging application. > > I've added a static constructor to the LogManager class to > make it work similarly to the log4j LogManager. After some > additional testing, I will contribute a patch to Jira. If > you have concerns about approach, please let me know. > > Thanks, > Pat. > > > -----Original Message----- > From: Conant, Patrick D > Sent: Monday, June 06, 2005 10:08 AM > To: Log4NET Dev > Subject: RE: System-wide configuration for log4net > > Thanks, Nicko. I agree that a custom attribute would be the > easiest way to do this. I guess I want to make sure that my > approach is aligned with the log4net development plan - and > that it can be contributed back to the project. > > A little background -- we used to struggle with log4j > configuration because every webapp in our tomcat environment > would re-initialize a shared log4j library on startup, so the > last webapp would "win" and take over the log4j > configuration. The solution to this was to have none of the > webapps initialize the logging library. A tomcat startup parameter > ("-Dlog4j.configuration=file://...") allowed log4j to > configure itself when it was first called. > > I'd like to find (or build) a similar solution for .NET. I'd > like any particular assembly to be able to leverage log4net > without having to configure it, without even having an > assembly-level attribute to give a hint as to where > configuration info is kept. Delving a little deeper into the > code, it seems to me that the way to do this is to add a > check for the "log4net.configuration" attribute to the > XmlConfigurator - either before or after checking for the > <log4net> element. This meets my goal of enabling a > system-wide log4net configuration (with the file URL set in > machine.config), but it also alleviates assembly or app > developers from having to initialize log4net via the > XmlConfiguratorAttribute. > > What are your thoughts on this approach? > > Thanks, > Pat. > > > > -----Original Message----- > From: Nicko Cadell [mailto:[EMAIL PROTECTED] > Sent: Monday, June 06, 2005 3:50 AM > To: Log4NET Dev > Subject: RE: System-wide configuration for log4net > > Patrick, > > The best way to do this is to write your own attribute that > extends the ConfiguratorAttribute. You can do this in your > own code without needing to modify log4net at all. It should > be relatively simple to create an attribute that loads the > XML config file path from the app settings. > > I have attached a simple example that you can use as a basis. > > Cheers, > > Nicko > > > > -----Original Message----- > > From: patrick conant [mailto:[EMAIL PROTECTED] > > Sent: 03 June 2005 19:35 > > To: [email protected] > > Subject: System-wide configuration for log4net > > > > I'm interested in creating a mechanism to have a system-wide > > configuration file for all .NET applications using log4net. > > I'd like all logging statements from various web applications and > > other .NET services to be managed via one configuration file. I > > haven't found a good way to do that with the existing code > base. I've > > used log4j for years, and have always passed > > "-Dlog4j.configuration=..." into my application startup. There > > doesn't seem to be a similar mechanism in log4net. > > > > I'm considering a couple options for addressing this, and I'd > > appreciate any recommendations or feedback. > > > > * Create an ConfiguratorAttribute class that looks for an > environment > > variable ("log4net.configuration") in order to locate the log4net > > configuration file. > > * Create a ConfiguratorAttribute class that retrieves config file > > location from a machine.config appSettings key (e.g. > > <add key=3D"log4net.configuration" > > value=3D"file:///C:/log4net.xml" />) > > * Update the XmlConfigurator to use one or both of these > methods for > > finding the configuration details. > > > > Any thoughts on the best way to proceed? > > > > Thanks, > > Pat. > > > > >
