Improving the WCF logger
One of the first improvement to the WCF logger is the ability to choose the list of logger to monitor during registration. A real application can generate tons of logs, suppose you are interested only in looking at the NHibernate generated query. The solution is to add another registration method and internally use an object that keeps care of the registration and senting log progress. Here is the new interface
|
|
Now I can choose the name of the logger I’m interested to filter messages log.
But this is not the only improvement I need. Quite often it happens that developer X called you telling When I press the button Y the application responds after 20 seconds, then you see with the SQL profiler that tons of query gets issued to the database. For a layered and complex application it can be difficult to understand where that queries are issued in the code, so I need a way to get a valid stack trace from the logger. To accomplish this task I modified the LogMessage object
|
|
First I have inserted in the message a list of stacksteps, a class that contains filename and line number, in the constructor of the message I use the StackTrace.NET class to obtain the stack trace, then I do a linq query to remove all the steps that have no source file or are part of my logging system. The result is really interesting.
Not only I’m able to intercept NHibernate generated SQL, but I have a full stack trace that tells me where the query is generated, now the next step is to build a better client interface to present the result in a more usable and readable form.
alk.
Tags: log4net NHibernate