Re: [Netcommon-developer] Common.Logging/callsite question

[Mark P. <mpo...@in...>]

Hi,

As for #2, I wanted to keep things to the lowest common denominator to
ensure supporting the widest range of libraries.  As with all lowest common
denominator solutions, the API could be more convenient.

>From looking into the code it seems like log4net and NLog both support this
functionality directly in the API.   In log4Net it would be achieved via
Logger.Log(LogEvent) and in NLog via the Logger.Log(Type, LogEventInfo)
methods.  We should look into EntLib and the others in this regard so we can
make an informed decision.  If a library doesn't support it though we can
add that functionality into Common.Logging.  The only real requirement is
that the target logging library allow hints to put in the appropriate
callsite. 

Regards,
Mark






-----Original Message-----
From: Adrian Rodriguez [mailto:aro...@ef...] 
Sent: Tuesday, September 11, 2007 2:37 PM
To: Mark Pollack; net...@li...
Subject: RE: [Netcommon-developer] Common.Logging/callsite question

Thank you!  I'm finding a few more question as we start incorporating
netcommon into our projects.

1) There seems to be no Trace() method... HEY... I just got an email
saying you'll schedule this in 1.2...thanks!

2) The logging calls only take (object) or (object, Exception).  While
this works, it would be nice to have calls much like NLog's overloads:
Debug(string message, params object[]) and Debug(IFormatProvider
provider, string message, params object[]).  The reason is, we'd like to
not take the hit in constructing a formatted string.

With NLog, I can do this

Logger.Debug("Evaluating data={0} with some other stuff={1}", fooOne,
fooTwo);

I don't have to put if (Logger.IsDebugEnabled) guards around the code.

If I use netcommon, I have to:

if (IsDebugEnabled)
{
    ILog.Debug(String.Format("Evaluating data={0} with some other
stuff={1}", fooOne, fooTwo));
}

I have to use the guards because I have to do the String.Format() since
the interface only takes an object.

Of course I'm not sure if this is a limitation simply because the other
logging libraries (log4net, enterprise logging, etc) don't support such
functionality so pardon my ignorance =).

<adrian />


-----Original Message-----
From: Mark Pollack [mailto:mpo...@in...] 
Sent: Tuesday, September 11, 2007 11:24 AM
To: 'Mark Pollack'; Adrian Rodriguez;
net...@li...
Subject: RE: [Netcommon-developer] Common.Logging/callsite question

Hi,
I'm making the fixes now.  I'll have a point release up on the site
later
tonight.
Cheers,
Mark


-----Original Message-----
From: net...@li...
[mailto:net...@li...] On Behalf Of
Mark
Pollack
Sent: Tuesday, September 11, 2007 2:10 PM
To: 'Adrian Rodriguez'; net...@li...
Subject: Re: [Netcommon-developer] Common.Logging/callsite question

Hi,
I saw your post on the NLog list, seems we should create a log call
using
LogEvent.  I'll add that as an issue to fix.  If you are keen to
contribute
a patch for that, please let me know.  Sorry for the delay in
responding.
Cheers,
Mark


-----Original Message-----
From: net...@li...
[mailto:net...@li...] On Behalf Of
Adrian Rodriguez
Sent: Friday, September 07, 2007 2:41 PM
To: net...@li...
Subject: [Netcommon-developer] Common.Logging/callsite question

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.

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

Thanks.

<adrian />



------------------------------------------------------------------------
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer


------------------------------------------------------------------------
-
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/
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer