logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicko Cadell" <ni...@neoworks.com>
Subject RE: log4net.Plugins
Date Wed, 24 Aug 2005 13:00:41 GMT

> -----Original Message-----
> From: Ron Grabowski [mailto:rongrabowski@yahoo.com] 
> Sent: 23 August 2005 18:41
> To: log4net-user@logging.apache.org
> Subject: log4net.Plugins
> Can plugins be added via the config file?

Not at the moment.

> Are plugins processed before or after the other elements of 
> the config file have been processed?

Handling plugins via the config file is a little tricky and is probably
the main reason why we don't support it at them moment. 
It is difficult to know if plugins should be reset / reloaded if the
config file is reloaded (e.g. by watching). 
The only plugin that ships with log4net is the
RemoteLoggingServerPlugin. This plugin is listening for logging events
from a remote server and I don't think that it would appreciate being
shutdown and recreated each time the config file is modified.

It needs some thinking about to fit it into the model we have for the
config file.

> Is it possible for a 
> plugin to hook into the "pre-initialize Appender" code 
> somehow (i.e. call the appender's constructor, pass it to the 
> plugin, then assign the appender's properties)?

No not really. There is no event raised when an appender is created.
Presumably you would want to get at the appender just before
ActivateOptions is called. Note that this would only be possible for
appenders read by the config parser not for appenders created

The plugin can hook the ILoggerRepository.ConfigurationChanged event and
find the relevant appender and update its properties, but this isn't as
easy as the above.

> I couldn't find any tests in:
>  /logging-log4net/tests/src/

We would like to have more tests :)

> or on the website. How does one add a plugin to log4net?



Using an assembly attribute on your application (next to your
configurator attribute)


> Above these lines in DefaultRepositorySelector.cs:
>  // Look for plugins defined on the assembly			
> LoadPlugins(repositoryAssembly, rep);

This is the code that looks for the Plugin attribute.

> There is this line:
>  // Look for aliasing attributes				
> 		 LoadAliases(repositoryAssembly, rep);
> What does mean to alias a repository?

Ok, this has nothing to do with plugins. (And it is a little
complicated, here goes)

By default all the separate assemblies that make up your application use
the same logging repository. That means that if 2 assemblies both ask
for a logger with the same name they will get back the same logger. The
logger repository has 1 configuration that is used by all the assemblies
in the application. This default behaviour is usually what you want and
we don't talk about these options very much as it just confuses people.

Let us assume that in your application there is an assembly that you
want to have use a different logging configuration. In that assembly you
can specify the RepositoryAttribute. This attribute allows you to
specify a different named repository. If the repository does not exist
it is created. Using a name allows several assemblies to share this
'other' repository.

So you can see that this allows the logger space to partitioned into
separate areas that have independent configuration.

Sometimes you have a 3rd party assembly that specifies a named
repository using the RepositoryAttribute and you decide that you don't
want to partition the logger space at all. This is where aliases come
in. In your main assembly you can specify an AliasRepositoryAttribute
attribute that joins a separate repository into the repository for your
assembly. i.e. it allows you to reverse the behaviour of the

I said it was complicated :)


> Thanks,
> Ron

View raw message