I'm really amazed that how many exceptions are being thrown by various components within the system. Since exceptions are costly I was digging into one of them related to Log4Net.
This is the exception that happens for every request which is using the logging module, during log4net initialization:
log4net:ERROR XmlConfigurator: Failed to initialize configuration file watcher for file [C:\Workspace\CleanGold\Main\Src\Tombarany Orchard\src\Orchard.Web\log4net.config]
System.Security.SecurityException: Request failed.
at log4net.Config.XmlConfigurator.ConfigureAndWatchHandler..ctor(ILoggerRepository repository, FileInfo configFile)
at log4net.Config.XmlConfigurator.ConfigureAndWatch(ILoggerRepository repository, FileInfo configFile)
The action that failed was:
The type of the first permission that failed was:
The Zone of the assembly that failed was:
This exception raised because the LoggingModule only registers the type for Log4netFactory and the ILoggerFactory interface and not an instance.
Log4netFactory's default constructor is initializing with "log4net.config" filename, which in our case will be checked within the root of the website. This kind of initialization is not picking up the log4net.config value from the appSettings of
our web.config, which is problem #1.
Problem #2 is that this default implementation of Log4netFactory is configuring XmlConfiguration with a FileInfo object and when the XmlConfiguration class is accessing it's FullName property the SecurityException raised. It's our "luck" that XmlConfigurator
has an override which takes a StreamReader or one which takes a XmlElement (more on this later).
Problem #3 is that XmlConfigurator is initialized by the default implementation with ConfigureAndWatch (SecurityException number n raised here for the same reason), which installs a FileSystemWatch handler for log4net's config file. For me it's a no brainer,
since we are using Log4Net per HTTP Request, and it's very unlikely that someone will tamper the config during a HTTP request, or if someone does I don't think that we should handle that situation in our scenario, so the plain Configure method should be enough
for us since a file system watcher is just system resource wasting!
Problem #4 for me is a performance point of view that XmlHierarchyConfigurator is forcing the environment variable expansion for all properties and does not remember if the previous expansion failed, the other one that it calls Environment.GetEnvironmentVariables()
for each property and also not caching this list. Taking into account a big Orchard site and lot of concurrent users I think that these things can cause performance problems. I'm wondering what should be the performance difference on live.visitmix.com if this
error get a fix!
So if we like to get rid of this error we have some possible solution at our disposal! We should just pick one!
Since in my terms this is a bug, but needs to discussion with the team and peers on how to fix it, that's why I started this as a discussion and not a bug.