Logging - Log4Net vs NLog

[Shannon Deminick]

Hi,

I've actually implemented log4net already in 4.10 but noticed there's been some discussion on the issues thread here based on whether we should use NLog instead.

http://issues.umbraco.org/issue/U4-7 

I've not used NLog before but considering that it is under active development seems to be pretty good. The other thing is that Log4Net doesn't support medium trust out of the box and I've had to recompile the source with an additional assembly attribute to ensure it works in medium trust. Perhaps if NLog supports medium trust out of the box this could be another +1 for it instead.

The last thing to note is that the log4net implementation in 4.10 is very similar to the v5 one we had and that we are using a custom logger that logs asychronously. This is an absolute must have so that it doesn't interfere with the performance of the website. I think that I read that NLog has this built in by default. If so, then that is great, if not then we'd need to create a custom logger to support it and in this case I think we'd just stick to what we have since we know it works, there's unit tests written for it, etc...

Let me know what you guys think.

[Aaron Powell]

Having read that issue it looks like a bit of bikeshedding. The reason people go to log4net as the logging library of first thought is that it’s been around for so long it’s almost staple in open source projects. I think this is an important factor that if we have a logging library that other projects are using when people integrate them (or we consume an external dependency) we can enable their logging too so we can trace errors.

 

Looking at the issue register there’s an outstanding issue regarding medium trust (https://issues.apache.org/jira/browse/LOG4NET-347) so if you’ve fixed it maybe just send them a patch.

 

On the point of whether log4net is an active project, it’s under the ASF umbrella (which is also where Lucene.NET is) and they have pretty strict rules about whether a project is alive or dead. If it’s still part of ASF then it’s still alive. But more importantly just _how much_ development does there need to be done on a logging library?

 

With the final point of logging asynchronously I think the better question is how much logging is being done that you are finding the UI being less responsive? I think there’s a better to look at the logging being done and work out if you actually need to log that much stuff. I’ve never come across a project that’s been slowed down by logging…

 

Aaron Powell
MVP - Internet Explorer (Development) | FunnelWeb Team Member

http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | Github | BitBucket

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.
To post to this group, send email to umbra...@googlegroups.com.
To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/HblA55XJj5MJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Shannon Deminick]

Well log4net is in there as I mentioned, just figured it was worthwhile getting feedback. I'm happy to leave it cuz it is already done and working but if there's strong reason to go with NLog I'm all ears.

(sent from my Galaxy S II)

[Scott Williams]

I only brought up the Nlog vs log4net talk on the issue tracker to make sure it at least got thought about rather then just grabbing for the fist solution that we came across.

Looking at nlog it also doesn't seem to support medium trust for the full .net framework out of the box(http://nlog.codeplex.com/workitem/6400) and would also require a custom build so I would just stick with log4net atm as the APIs aren't to dissimilar it could be swapped out at a later point without to much trouble.

Scott.