I had thought about adding <plugin> node parsing support to the xml config file
(see this link for Nicko's comments about plugins: http://tinyurl.com/jadcc):
<log4net>
<plugin name="MyPlugin" type="Company.MyPlugin" />
<appender name="FileAppender" type="log4net.Appender.FileAppender">
<file value="log.txt" />
<layout type="log4net.Layout.SimpleLayout" />
</appender>
<root>
<level value="ALL" />
<appender-ref ref="FileAppender" />
</root>
<myCustomerConfigNode>
<appender-ref ref="FileAppender" />
</myCustomerConfigNode>
</log4net>
The plugin could attach to configuration events similiar to how a an
IHttpModule is able to attach to an HttpApplication's events:
// pseudo code
public class MyPlugin : PluginSkeleton
{
// similiar to IHttpModule.Init
public override void Attach(ILoggerRepository repository)
{
base.Attach(repository);
// repository is similiar to HttpApplication
Hierarchy hierarchy = (Hierarchy)repository;
hierarchy.ConfigurationParseUnknownElement +=
new
HierarchyConfigurationParseUnknownElementEventHandler(hierarchy_ParseUnknownElement);
}
private void hierarchy_ParseUnknownElement(object sender,
HiearchyConfigurationEventArgs e)
{
Hierarchy hierarchy = (Hierarchy)sender;
if (e.UnknownElement.LocalName == "myCustomerConfigNode")
{
// iterate through every appender-ref node
foreach (XmlNode node in e.UnknownElement.ChildNodes)
{
IAppender appender =
e.XmlHierarchyConfigurator.FindAppenderByReference(node);
// [snip]
}
}
}
}
One of the problems with that code is even if we're able to successfully attach
to the unknown element parsing event the Hierarchy will see the
<myCustomerConfigNode> node and attempt to set that property on the Hierarchy
instance which means we'll see error messages in the internal log files about
MyCustomerConfigNode not being a property on Hierarchy. Anyone think its a good
idea to go the plugin route?
----- Original Message ----
From: Igor Trofimov <[EMAIL PROTECTED]>
To: Log4NET User <[email protected]>
Sent: Friday, December 22, 2006 2:08:57 AM
Subject: Re: XmlHierarchyConfigurator
Yes! It would be great!
And what about this small modification? :)
2006/12/22, Ron Grabowski <[EMAIL PROTECTED]>: The call to SetParameter
(XmlHierarchyConfigurator.cs:185) in the foreach loop inside the Configure
method could be replaced with a call to ParseUnknownElement:
protected virtual ParseUnknownElement(XmlElement xmlElement, Hierarchy
hierarchy)
{
SetParameter(xmlElement, hierarchy);
}
to match ParseLogger, ParseRenderer, etc. That would allow you do extend
XmlHierarchyConfigurator and do custom processing on user defined top level
elements. The default behavior of calling SetParameter would remain the same.
----- Original Message ----
From: Igor Trofimov <[EMAIL PROTECTED]>
To: Log4NET User <[email protected] >
Sent: Sunday, December 17, 2006 1:37:21 PM
Subject: Re: XmlHierarchyConfigurator
Well, i want to add recognition of my specific elements in hierarchy
configuration, similar to <logger>.
And this elements can contain <appender-ref> elements (just as logger do)
with reference to some appender - so, i can't use default capabilities of
SetParameter - there can't be sutable add-method for "appender-ref".
---------------
You wrote to "Log4NET User" < [email protected]> on Sun, 17 Dec
2006 10:02:22 -0800 (PST):
RG> XmlHierarchyConfigurator seems like a fairly complex class that was
RG> designed to parse a particular file structure without much thought for
RG> extensibility (its probably not a good thing to encourage people to use
RG> their own slightly different configuration file structure). Take the
RG> SetParameter method for example...making that virtual (~250 lines)
RG> would allow you to change how parameters are set but my guess is that
RG> you'd still need to copy and paste a lot of that code to get your
RG> override to perform similiar to the base method.
RG> What parts of XmlHierarchyConfigurator do you want to override?
