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