[
https://issues.apache.org/jira/browse/LOG4NET-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558003#action_12558003
]
Manuel Riezebosch commented on LOG4NET-133:
-------------------------------------------
Indeed, I can come away with it. I see that
SystemInfo.ConfigurationFileLocation returns the correct location of the
configfile. But still, the Log4NetConfigSectionHandler is not used at all ;)
The problem is that it is required to have the XmlConfiguratorAttribute on an
assembly as soon as it uses log4net, otherwise the config will not be loaded.
One problem is that when I set the ConfigFile parameter on the
XmlConfiguratorAttribute, it only applies to logging calls from that assembly.
When I call a function from a class from another assembly, the
ConfiguratorAttributes from thát assembly are looked up and the parameters of
the original assembly are ignored. The only way to circumvent this is using the
log4net.Config option in the AppSettings.
But I can also live with that (for now).
> Unable to use default config loading
> ------------------------------------
>
> Key: LOG4NET-133
> URL: https://issues.apache.org/jira/browse/LOG4NET-133
> Project: Log4net
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.10
> Reporter: Manuel Riezebosch
>
> Default config loading from app.config with the Log4NetConfigSectionHandler
> is not possible, because XmlConfiguratior.Configure(ILoggerRepository
> repository), where the ConfigurationManager is used, never gets called.
> The DefaultRepositorySelector.ConfigureRepository only loads config when the
> (Xml)ConfiguratorAttribute is found in the loaded assembly and calls
> Configure(assembly, repository) on this attribute. When using the
> XmlConfiguratorAttribute, the XmlConfigurator.Configure(targetRepository,
> configFile) gets called, which doesn't use the ConfigurationManager but an
> XmlDocument instead.
> The most annoying thing is that you are required now to use the
> XmlConfiguratorAttribute on assembly level, because otherwise the
> configuration is ignored. See DefaultRepositorySelector line 657 for more
> details. This is a problem when using calling functions in external
> assemblies, for instance with unit testing, because the logging from the
> tested object is ignored because the configuration fails to load.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
