Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   ASP .Net (http://www.velocityreviews.com/forums/f29-asp-net.html)
-   -   Re: General question about logging concept (http://www.velocityreviews.com/forums/t384697-re-general-question-about-logging-concept.html)

Samuel R. Neff 01-04-2007 02:42 PM

Re: General question about logging concept
 

Once you configure logging it's configured for the entire appdomain,
not just the web dll's. The other projects in your web application
can also use the configured logging functionality.

I would recomment not putting logging information in web.config and
instead create a log.config file and configure logging from that. The
reason is log4net can watch file file and change logging parameters
on-the-fly without reloading the application. However, if you have
logging configured through web.config any changes to web.config will
cause the app to reload.

The most common approach I've seen to logging is that each class will
have an instance method defined:

private ILog log = LogManager.GetLogger(GetType());

Then within each class you can use log.Error(), log.Debug() etc.
Static method logging would have to be handled differently.

Personally I don't like this approach because it requires a lot of log
variables declared everywhere and it requires that all projects
reference the log4net dll (I believe 3rd party dll's should be
isolated to one project only whenever possible to reduce the
maintenance hassles of upgrades or migration).

What I've done is create my own static Log class which has methods
corresponding to ILog (but is not itself an ILog implementation) and
passes those calls along to log4net.

So I would have somethign like this:

public static void Error(Type t, string message)
{
LogManager.GetLogger(t).Error(message);
}

public static void Error(object t, string message)
{
Error(t != null ? t.GetType() : typeof(Log), message);
}


Which can be called from anywhere in the application. The downside is
you have to pass the type or object for each log message, but upside
is log4net is isolated and the code impact on the rest of our
application is minimal. Also one downside to this approach is
GetLogger() is called for each log message instead of simply Error()
which may have a performance penalty, although even with heavy logging
it's not noticeable (heaving as in thousands of log messages a minute
during certain debugging times). I haven't profiled the GetLogger()
calls yet but from actual experience it seems this approach is fine.

Also, the above is an oversimplification--there are actually 12
overloads each of Debug, Info, Warn, and Error.

HTH,

Sam


------------------------------------------------------------
We're hiring! B-Line Medical is seeking Mid/Sr. .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.



On Thu, 4 Jan 2007 02:54:00 -0800, ???? ???????
<@discussions.microsoft.com> wrote:

>Hi,
>I'm just now configuring some logging module in my web app (I'm using
>log4net).
>The web app consists of web site and multiple library projects.
>Each has to log events. So, probably there is a need for a central component
>(probably static one) which receive messages and log them.
>I don't want each code to instantiate the logger class, this is bad practice
>with respect to performance & modular design aspects.
>
>1. If i configure my logging module in web.config, wouldn't it be available
>only
>to the web site?
>2. Where & how would you create class that responsible for getting all the
>messages and log them into log4net?
>Will it be simple static class? is it belongs to the web site? external
>specific project?
>
>Thanks.



Samuel R. Neff 01-04-2007 10:09 PM

Re: General question about logging concept
 

you can have a different logger for each assembly, or namespace, or
class. It's totally configurable. It's even configurable on the fly
so say your program is running in production and you have logging set
to Info and you need to debug a problem you can in production change
the log.config file to set the debug level for a particular namespace
or class to Debug to get more log messages (assuming you have more
messages in the code).

Also, by default the log messages include the logger info, so it's a
good way to get source info into log messages.

However, if you're building a custom Log class with all static methods
you can choose to ignore the type parameter and always get the same
logger (log4net caches loggers so repeated calls to GetLogger are
quick).
HTH,

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking Mid/Sr. .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.



On Thu, 4 Jan 2007 13:11:02 -0800, ???? ???????
<@discussions.microsoft.com> wrote:

>Samuel,
>Thanks for your excellent answer.
>I don't understand one thing with log4net:
>why to retrieve a logger u pass the assembly name?
>It's not that you define a logger for each assembly in the system...
>I have only one logger, why not just call it:
>getLogger("file")
>?
>
>Thanks.
>
>"Samuel R. Neff" wrote:
>
>>
>> Once you configure logging it's configured for the entire appdomain,
>> not just the web dll's. The other projects in your web application
>> can also use the configured logging functionality.
>>
>> I would recomment not putting logging information in web.config and
>> instead create a log.config file and configure logging from that. The
>> reason is log4net can watch file file and change logging parameters
>> on-the-fly without reloading the application. However, if you have
>> logging configured through web.config any changes to web.config will
>> cause the app to reload.
>>
>> The most common approach I've seen to logging is that each class will
>> have an instance method defined:
>>
>> private ILog log = LogManager.GetLogger(GetType());
>>
>> Then within each class you can use log.Error(), log.Debug() etc.
>> Static method logging would have to be handled differently.
>>
>> Personally I don't like this approach because it requires a lot of log
>> variables declared everywhere and it requires that all projects
>> reference the log4net dll (I believe 3rd party dll's should be
>> isolated to one project only whenever possible to reduce the
>> maintenance hassles of upgrades or migration).
>>
>> What I've done is create my own static Log class which has methods
>> corresponding to ILog (but is not itself an ILog implementation) and
>> passes those calls along to log4net.
>>
>> So I would have somethign like this:
>>
>> public static void Error(Type t, string message)
>> {
>> LogManager.GetLogger(t).Error(message);
>> }
>>
>> public static void Error(object t, string message)
>> {
>> Error(t != null ? t.GetType() : typeof(Log), message);
>> }
>>
>>
>> Which can be called from anywhere in the application. The downside is
>> you have to pass the type or object for each log message, but upside
>> is log4net is isolated and the code impact on the rest of our
>> application is minimal. Also one downside to this approach is
>> GetLogger() is called for each log message instead of simply Error()
>> which may have a performance penalty, although even with heavy logging
>> it's not noticeable (heaving as in thousands of log messages a minute
>> during certain debugging times). I haven't profiled the GetLogger()
>> calls yet but from actual experience it seems this approach is fine.
>>
>> Also, the above is an oversimplification--there are actually 12
>> overloads each of Debug, Info, Warn, and Error.
>>
>> HTH,
>>
>> Sam
>>
>>
>> ------------------------------------------------------------
>> We're hiring! B-Line Medical is seeking Mid/Sr. .NET
>> Developers for exciting positions in medical product
>> development in MD/DC. Work with a variety of technologies
>> in a relaxed team environment. See ads on Dice.com.
>>
>>
>>
>> On Thu, 4 Jan 2007 02:54:00 -0800, ???? ???????
>> <@discussions.microsoft.com> wrote:
>>
>> >Hi,
>> >I'm just now configuring some logging module in my web app (I'm using
>> >log4net).
>> >The web app consists of web site and multiple library projects.
>> >Each has to log events. So, probably there is a need for a central component
>> >(probably static one) which receive messages and log them.
>> >I don't want each code to instantiate the logger class, this is bad practice
>> >with respect to performance & modular design aspects.
>> >
>> >1. If i configure my logging module in web.config, wouldn't it be available
>> >only
>> >to the web site?
>> >2. Where & how would you create class that responsible for getting all the
>> >messages and log them into log4net?
>> >Will it be simple static class? is it belongs to the web site? external
>> >specific project?
>> >
>> >Thanks.

>>
>>




All times are GMT. The time now is 10:55 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.