NLog comments

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

NLog comments

Mark Sironi
I have just finished going through my code and replacing my own logging code
with NLog in some of my infrastructure code for the next release of a
software project I run (http://d20spellbook.home.comcast.net).  I have a few
comments I would like to pass along.

It would be nice if the Logger.XXXException methods had an overload that
allowed for formatting the output message, i.e.:

void XXXException(Exception e, string format, params object[] args);

I had this in my own logging code and going through all of the places where
I caught exceptions and effectively changing 1 line of code (the log entry)
into 2 (1 to build the string and 1 to log it) was mildly annoying.

My product has many assemblies, ideally I would like to keep NLog references
out of all of them but 1; isolating the NLog code behind my own wrapper to
minimize the impact of any changes made to NLog and to allow migration to
some other logging system if it ever became more appropriate.  The problem
with doing that as the code is now constructed is the stack tracing, my log
wrapper class would always show up as the type that generated the logging
statement.

What would be really nice is if the LogManager provided a factory method
like the following:

Logger GetLogger(string name, Type wrapperType);

Where wrapperType would be the type of the class used to wrap NLog.  This
would have to be pushed down to the Logger type, and it would need to ignore
both its type and this type when performing the stack trace.

This would allow someone to wrap NLog to isolate it yet still provide the
correct signature information for the log entry.

A suggestion I would make (although it doesn't really matter in the short
term) would be to place all of the logging business logic into an interface
and change the LogManager to return interface references instead of object
references.  This would open the door to all sorts of possibilities in the
future.

I do have to say I am very impressed with the configuration, it is both
simple and powerful and was one of the primary factors in my decision to
switch to NLog.

Thanks for reading,

--
Mark Sironi




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list
Reply | Threaded
Open this post in threaded view
|

Re: NLog comments

Jarek Kowalski
Administrator
Hi Mark,

Comments inside:

> It would be nice if the Logger.XXXException methods had an overload that
> allowed for formatting the output message, i.e.:
>
> void XXXException(Exception e, string format, params object[] args);
>
> I had this in my own logging code and going through all of the places
> where
> I caught exceptions and effectively changing 1 line of code (the log
> entry)
> into 2 (1 to build the string and 1 to log it) was mildly annoying.

This can be done. The PERL source code to generate the necessary overloads
(no, I haven't written them myself) is in tools\generate_overloads.pl. Feel
free to tweak it and submit the results to the mailing list once you're sure
that adding all these overloads is really needed. (You should be able to use
any perl to run the script, this one is ok:
http://www.activestate.com/Products/ActivePerl/?mp=1)

> My product has many assemblies, ideally I would like to keep NLog
> references
> out of all of them but 1; isolating the NLog code behind my own wrapper to
> minimize the impact of any changes made to NLog and to allow migration to
> some other logging system if it ever became more appropriate.  The problem
> with doing that as the code is now constructed is the stack tracing, my
> log
> wrapper class would always show up as the type that generated the logging
> statement.

True.

> What would be really nice is if the LogManager provided a factory method
> like the following:
>
> Logger GetLogger(string name, Type wrapperType);

I thought about it, too. This "wrapperType" would be required to inherit
from NLog.Logger, but I don't think this is a big problem as one of the
things the wrapper would do would be calling the logger methods.

> Where wrapperType would be the type of the class used to wrap NLog.  This
> would have to be pushed down to the Logger type, and it would need to
> ignore
> both its type and this type when performing the stack trace.

NLog.LoggerImpl class is already prepared for this. It accepts the first
parameter which is a wrapper type. Some tweaks need to be applied to Logger
and LogManager classes, but other than that - yes. It's definitely doable.
Unfortunately I don't have time to take a look at this right now, but feel
free to provide a patch. I'll be happy to commit it.

There are some questions that need to be answered. Assuming someone calls:

l1 = LogManager.GetLogger(name)

then

l2 = LogManager.GetLogger(name,typeof(...))

Should l1 == l2 ? What about the other order of the calls?

> A suggestion I would make (although it doesn't really matter in the short
> term) would be to place all of the logging business logic into an
> interface
> and change the LogManager to return interface references instead of object
> references.  This would open the door to all sorts of possibilities in the
> future.

I disagree. Using interfaces has some serious performance cost (interface
dispatch takes more time than virtual dispatch and MUCH more time than
non-virtual method calls). Among other things NLog is about speed (not
having to remove logging statements at compile time but at runtime). Any
added cost here would probably change the behaviour of many applications
which rely on the speed.

It would be great if you could suggest the structure for the interface. How
many methods/overloads whould it include?

Jarek



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list
NLog Blog