NLog and Commons.Logging question

[Adrian Rodriguez-2]

Hi.  I have a question concerning the use of NLog with Commons.Logging
from netcommon.sf.net.  We're trying to evaluate a solution where we
don't have to stick to a particular logging implementation.  We found
netcommon, but we're having some trouble with it and I haven't received
any responses from either list so I figured I would ask here.  I have 2
questions:

Question 1)
Here is the question I asked to netcommon and springnet-developer:

We started using common logging with nlog.  Unfortunately, the nlog
${callsite} always renders the method name in Common.Logging.  Has
anyone here been through this before?  I want the ${callsite} to render
the method I called Common.Logging from.  If I don't have this, I don't
know where the message came from.  Would the right way be to use
${stacktrace} instead of ${callsite}?

If anyone could provide some help in this area, I'd be very grateful.

Question 2)
It was suggested that we go through a single shared logger instead of
doing LogManager.GetCurrentClassLogger().
If we had some static logger like:

namespace MyCompany
{
    public static class Logging
    {
        private static Logger logger = LogManager.GetLogger("My Company
Logger");
        public static Logger
        {
            get { return logger; }
        }
    }
}

And used it like Logging.Logger.Debug(), Trace(), etc...will this cause
any performance problems since we are only using one logger instead of
creating one in every class?

Any help on this would be great.  If anyone has any experience going
through this at your company (not being tied to a particular logging
implementation), I'd really appreciate your input.

Thanks.

<adrian />


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list

[Andrew Stone-2]

I had these questions too.

If you use NLog as intended, IE: LogManager.GetCurrentClassLogger()
The callsite layout renderer will work as expected, and the logger name will be that of the class.

Using the recommended approach keeps things simple and you don't have to worry about any unexpected problems.

;)
Stonie.

On 11/09/2007, Adrian Rodriguez <[hidden email]> wrote:

Hi.  I have a question concerning the use of NLog with Commons.Logging
from netcommon.sf.net.  We're trying to evaluate a solution where we
don't have to stick to a particular logging implementation.  We found
netcommon, but we're having some trouble with it and I haven't received
any responses from either list so I figured I would ask here.  I have 2
questions:

Question 1)
Here is the question I asked to netcommon and springnet-developer:

We started using common logging with nlog.  Unfortunately, the nlog
${callsite} always renders the method name in Common.Logging.  Has
anyone here been through this before?  I want the ${callsite} to render
the method I called Common.Logging from.  If I don't have this, I don't
know where the message came from.  Would the right way be to use
${stacktrace} instead of ${callsite}?

If anyone could provide some help in this area, I'd be very grateful.

Question 2)
It was suggested that we go through a single shared logger instead of
doing LogManager.GetCurrentClassLogger().
If we had some static logger like:

namespace MyCompany
{
    public static class Logging
    {
        private static Logger logger = LogManager.GetLogger ("My Company
Logger");
        public static Logger
        {
            get { return logger; }
        }
    }
}

And used it like Logging.Logger.Debug(), Trace(), etc...will this cause
any performance problems since we are only using one logger instead of
creating one in every class?

Any help on this would be great.  If anyone has any experience going
through this at your company (not being tied to a particular logging
implementation), I'd really appreciate your input.

Thanks.

<adrian />


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list

--
Kind regards,
----------------------------------------
Andrew Stone
Microsoft .NET Consultant

AndrewStone.net
[hidden email]
http://andrewstone.net
[phone]
----------------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list

[Jaroslaw Kowalski]

Ad 1:

It is possible to fix this ${callsite} behavior by preparing your own
LogEventInfo
object and sending it through Logger.Log(type,logEventInfo) overload. This
analyzes stack to produce real user call site.

http://svn.nlog-project.org/repos/nlog/trunk/NLog/examples/ExtendingLoggers/LoggerWrapper/Program.cs


Ad 2:

There will be no performance penalty in this case but you will lose the
ability to quickly filter by logger name. You may have to resort to using
filters and some of them can be pretty slow (especially if they involve
${callstack}-related tests).

As always, the first rule of performance/optimization is: Measure!

Jarek

----- Original Message -----
From: "Adrian Rodriguez" <[hidden email]>
To: <[hidden email]>
Sent: Monday, September 10, 2007 12:09 PM
Subject: [Nlog-list] NLog and Commons.Logging question

> Hi.  I have a question concerning the use of NLog with Commons.Logging
> from netcommon.sf.net.  We're trying to evaluate a solution where we
> don't have to stick to a particular logging implementation.  We found
> netcommon, but we're having some trouble with it and I haven't received
> any responses from either list so I figured I would ask here.  I have 2
> questions:
>
> Question 1)
> Here is the question I asked to netcommon and springnet-developer:
>
> We started using common logging with nlog.  Unfortunately, the nlog
> ${callsite} always renders the method name in Common.Logging.  Has
> anyone here been through this before?  I want the ${callsite} to render
> the method I called Common.Logging from.  If I don't have this, I don't
> know where the message came from.  Would the right way be to use
> ${stacktrace} instead of ${callsite}?
>
> If anyone could provide some help in this area, I'd be very grateful.
>
> Question 2)
> It was suggested that we go through a single shared logger instead of
> doing LogManager.GetCurrentClassLogger().
> If we had some static logger like:
>
> namespace MyCompany
> {
>    public static class Logging
>    {
>        private static Logger logger = LogManager.GetLogger("My Company
> Logger");
>        public static Logger
>        {
>            get { return logger; }
>        }
>    }
> }
>
> And used it like Logging.Logger.Debug(), Trace(), etc...will this cause
> any performance problems since we are only using one logger instead of
> creating one in every class?
>
> Any help on this would be great.  If anyone has any experience going
> through this at your company (not being tied to a particular logging
> implementation), I'd really appreciate your input.
>
> Thanks.
>
> <adrian />
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Nlog-list mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nlog-list
>A

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list

[Jaroslaw Kowalski]

BTW. If netcommon is not using wrapper approach described below, this is a
bug that should be filed in their tracker.

Jarek

----- Original Message -----
From: "Jaroslaw Kowalski" <[hidden email]>
To: "Adrian Rodriguez" <[hidden email]>;
<[hidden email]>
Sent: Monday, September 10, 2007 5:56 PM
Subject: Re: [Nlog-list] NLog and Commons.Logging question

> Ad 1:
>
> It is possible to fix this ${callsite} behavior by preparing your own
> LogEventInfo
> object and sending it through Logger.Log(type,logEventInfo) overload. This
> analyzes stack to produce real user call site.
>
> http://svn.nlog-project.org/repos/nlog/trunk/NLog/examples/ExtendingLoggers/LoggerWrapper/Program.cs
>
>
> Ad 2:
>
> There will be no performance penalty in this case but you will lose the
> ability to quickly filter by logger name. You may have to resort to using
> filters and some of them can be pretty slow (especially if they involve
> ${callstack}-related tests).
>
> As always, the first rule of performance/optimization is: Measure!
>
> Jarek
>
> ----- Original Message -----
> From: "Adrian Rodriguez" <[hidden email]>
> To: <[hidden email]>
> Sent: Monday, September 10, 2007 12:09 PM
> Subject: [Nlog-list] NLog and Commons.Logging question
>
>> Hi.  I have a question concerning the use of NLog with Commons.Logging
>> from netcommon.sf.net.  We're trying to evaluate a solution where we
>> don't have to stick to a particular logging implementation.  We found
>> netcommon, but we're having some trouble with it and I haven't received
>> any responses from either list so I figured I would ask here.  I have 2
>> questions:
>>
>> Question 1)
>> Here is the question I asked to netcommon and springnet-developer:
>>
>> We started using common logging with nlog.  Unfortunately, the nlog
>> ${callsite} always renders the method name in Common.Logging.  Has
>> anyone here been through this before?  I want the ${callsite} to render
>> the method I called Common.Logging from.  If I don't have this, I don't
>> know where the message came from.  Would the right way be to use
>> ${stacktrace} instead of ${callsite}?
>>
>> If anyone could provide some help in this area, I'd be very grateful.
>>
>> Question 2)
>> It was suggested that we go through a single shared logger instead of
>> doing LogManager.GetCurrentClassLogger().
>> If we had some static logger like:
>>
>> namespace MyCompany
>> {
>>    public static class Logging
>>    {
>>        private static Logger logger = LogManager.GetLogger("My Company
>> Logger");
>>        public static Logger
>>        {
>>            get { return logger; }
>>        }
>>    }
>> }
>>
>> And used it like Logging.Logger.Debug(), Trace(), etc...will this cause
>> any performance problems since we are only using one logger instead of
>> creating one in every class?
>>
>> Any help on this would be great.  If anyone has any experience going
>> through this at your company (not being tied to a particular logging
>> implementation), I'd really appreciate your input.
>>
>> Thanks.
>>
>> <adrian />
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Nlog-list mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/nlog-list
>>A
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Nlog-list mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nlog-list
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list