Menu
▾
▴
netcommon-developer — Discussion on the development of the netcommon libraries
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
| 2009 |
Jan
(16) |
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2010 |
Jan
(3) |
Feb
(3) |
Mar
(1) |
Apr
(5) |
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
(8) |
Oct
(18) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(3) |
Apr
(1) |
May
|
Jun
|
Jul
(4) |
Aug
(4) |
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
(13) |
Feb
(4) |
Mar
|
Apr
(2) |
May
(3) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
| 2013 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Werner C. <ite...@ho...> - 2010-05-05 08:10:10
|
Hi, I was wondering why Common.Logging designers chose NOT to use a static log class. For example you could just as well have created a facade around log4net that just used a default logger. Was that because the "logger structure" was a desired effect? Or because it would be easy for existing log4net users to adopt? Or perhaps some other reason? -- Werner _________________________________________________________________ |
|
From: Erich E. <eei...@gm...> - 2010-04-07 08:19:54
|
Hi Israel, thanks a lot for your input, I will fix that as soon as possible -Erich > -----Original Message----- > From: Israel Evans [mailto:hs....@gm...] > Sent: Friday, April 02, 2010 8:49 PM > To: net...@li... > Subject: [Netcommon-developer] Bridging System.Diagnostics.Trace to > NLog (bug fix) > > I have finally managed to set up a logging bridge from > System.Diagnostics.Trace to NLog. In my scenario, I am specifically > concerned with the Trace output from the System.Net namespace. I hope > this helps anyone else who is trying to bridge Bridging > System.Diagnostics.Trace to NLog. The code should fix should also > allow someone to bridge to log4net. > > There were a couple issues I had to work around. First, the > documentation on configuration is slightly wrong. Second, there is a > bug in Common.Logging.Factory.AbstractLogger. > > For my configuration, I have the following 2 files: app.config and > NLog.config > > My app.config looks like this: > > <configuration> > <configSections> > <sectionGroup name="common"> > <section name="logging" > type="Common.Logging.ConfigurationSectionHandler, Common.Logging" /> > </sectionGroup> > </configSections> > <common> > <logging> > <factoryAdapter > type="Common.Logging.NLog.NLogLoggerFactoryAdapter, > Common.Logging.NLog"> > <arg key="configType" value="FILE" /> > <arg key="configFile" value="~/NLog.config" /> > </factoryAdapter> > </logging> > </common> > <system.diagnostics> > <sharedListeners> > <add name="Diagnostics" > > type="Common.Logging.Simple.CommonLoggingTraceListener, > Common.Logging" > initializeData="DefaultTraceEventType=Verbose; > LoggerNameFormat=System.Net.All"> > <filter type="System.Diagnostics.EventTypeFilter" > initializeData="Verbose"/> > </add> > </sharedListeners> > <sources> > <source name="System.Net"> > <listeners> > <add name="Diagnostics" /> > </listeners> > </source> > </sources> > <switches> > <add name="System.Net" value="Verbose"/> > </switches> > <trace> > <listeners> > <add name="Diagnostics" /> > </listeners> > </trace> > </system.diagnostics> > </configuration> > > > and my NLog.config (in the same directory) looks like this: > > <nlog> > <targets> > <target name="trace" xsi:type="File" > fileName="${nlogdir}/System.Net.log" > > layout="${date:format=HH\:mm\:ss}|${level}|${stacktrace}|${message}"/> > </targets> > <rules> > <logger name="System.Net.*" minlevel="Trace" > writeTo="trace" /> > </rules> > </nlog> > > > Finally, I had to make a small bug fix in > Common.Logging.Factory.AbstractLogger by modifying the ToString() > method. (There are constructors invocations that supply null for the > IFormatProvider, but ToString() does not guard on that.) > > public override string ToString() > { > if (cachedMessage == null) > { > if (FormatProvider != null) > { > cachedMessage = string.Format(FormatProvider, > Message, Args); > } > else > { > cachedMessage = Message; > } > } > return cachedMessage; > } > > > > > Regards, > Iz > > ----------------------------------------------------------------------- > ------- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Netcommon-developer mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netcommon-developer |
|
From: Erich E. <eei...@gm...> - 2010-04-07 08:14:56
|
Wim, I am very sorry about this. This slipped through my attention. Of course we are very much interested to add a Silverlight integration and be happy to review and probably add your patch! -Erich From: wim...@gm... [mailto:wim...@gm...] Sent: Wednesday, April 07, 2010 6:37 AM To: Net...@li... Subject: Re: [Netcommon-developer] Silverlight No, nobody did. Regards, Wim On Apr 5, 2010 6:31pm, Bruno Baia <br...@gm...> wrote: > Did someone replied to him privatly ? > > > > > - Bruno > > 2010/3/12 wim...@gm...> > > Hi, > > The company I work for, has a shared library which depends on Common.Logging. > We would like to port this library to Silverlight. > > > I have created a patch for Common.Logging which supports Silverlight, with basic logging to System.Diagnostics.Debug and to the attached client-side console. > > Maybe this patch can be integrated in the trunk? > > Please send me an email if you are interested. > > Kind regards, > > Wim Vergouwe > ------------------------------------------------------------------------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > > Netcommon-developer mailing list > > Net...@li... > > https://lists.sourceforge.net/lists/listinfo/netcommon-developer > > > > > > |
|
From: <wim...@gm...> - 2010-04-07 05:37:23
|
No, nobody did. Regards, Wim On Apr 5, 2010 6:31pm, Bruno Baia <br...@gm...> wrote: > Did someone replied to him privatly ? > - Bruno > 2010/3/12 wim...@gm...> > Hi, > The company I work for, has a shared library which depends on > Common.Logging. > We would like to port this library to Silverlight. > I have created a patch for Common.Logging which supports Silverlight, > with basic logging to System.Diagnostics.Debug and to the attached > client-side console. > Maybe this patch can be integrated in the trunk? > Please send me an email if you are interested. > Kind regards, > Wim Vergouwe > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Netcommon-developer mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netcommon-developer |
|
From: Bruno B. <br...@gm...> - 2010-04-05 16:31:24
|
Did someone replied to him privatly ? - Bruno 2010/3/12 <wim...@gm...> > Hi, > > The company I work for, has a shared library which depends on > Common.Logging. > We would like to port this library to Silverlight. > > I have created a patch for Common.Logging which supports Silverlight, with > basic logging to System.Diagnostics.Debug and to the attached client-side > console. > > Maybe this patch can be integrated in the trunk? > Please send me an email if you are interested. > > Kind regards, > > Wim Vergouwe > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Netcommon-developer mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netcommon-developer > > |
|
From: Israel E. <hs....@gm...> - 2010-04-02 19:49:17
|
I have finally managed to set up a logging bridge from System.Diagnostics.Trace to NLog. In my scenario, I am specifically concerned with the Trace output from the System.Net namespace. I hope this helps anyone else who is trying to bridge Bridging System.Diagnostics.Trace to NLog. The code should fix should also allow someone to bridge to log4net. There were a couple issues I had to work around. First, the documentation on configuration is slightly wrong. Second, there is a bug in Common.Logging.Factory.AbstractLogger. For my configuration, I have the following 2 files: app.config and NLog.config My app.config looks like this: <configuration> <configSections> <sectionGroup name="common"> <section name="logging" type="Common.Logging.ConfigurationSectionHandler, Common.Logging" /> </sectionGroup> </configSections> <common> <logging> <factoryAdapter type="Common.Logging.NLog.NLogLoggerFactoryAdapter, Common.Logging.NLog"> <arg key="configType" value="FILE" /> <arg key="configFile" value="~/NLog.config" /> </factoryAdapter> </logging> </common> <system.diagnostics> <sharedListeners> <add name="Diagnostics" type="Common.Logging.Simple.CommonLoggingTraceListener, Common.Logging" initializeData="DefaultTraceEventType=Verbose; LoggerNameFormat=System.Net.All"> <filter type="System.Diagnostics.EventTypeFilter" initializeData="Verbose"/> </add> </sharedListeners> <sources> <source name="System.Net"> <listeners> <add name="Diagnostics" /> </listeners> </source> </sources> <switches> <add name="System.Net" value="Verbose"/> </switches> <trace> <listeners> <add name="Diagnostics" /> </listeners> </trace> </system.diagnostics> </configuration> and my NLog.config (in the same directory) looks like this: <nlog> <targets> <target name="trace" xsi:type="File" fileName="${nlogdir}/System.Net.log" layout="${date:format=HH\:mm\:ss}|${level}|${stacktrace}|${message}"/> </targets> <rules> <logger name="System.Net.*" minlevel="Trace" writeTo="trace" /> </rules> </nlog> Finally, I had to make a small bug fix in Common.Logging.Factory.AbstractLogger by modifying the ToString() method. (There are constructors invocations that supply null for the IFormatProvider, but ToString() does not guard on that.) public override string ToString() { if (cachedMessage == null) { if (FormatProvider != null) { cachedMessage = string.Format(FormatProvider, Message, Args); } else { cachedMessage = Message; } } return cachedMessage; } Regards, Iz |
|
From: <wim...@gm...> - 2010-03-12 11:39:45
|
Hi, The company I work for, has a shared library which depends on Common.Logging. We would like to port this library to Silverlight. I have created a patch for Common.Logging which supports Silverlight, with basic logging to System.Diagnostics.Debug and to the attached client-side console. Maybe this patch can be integrated in the trunk? Please send me an email if you are interested. Kind regards, Wim Vergouwe |
|
From: Erich E. <eei...@gm...> - 2010-02-03 11:35:57
|
? From: Oleg Ganin [mailto:ole...@et...] Sent: Tuesday, February 02, 2010 5:20 PM To: net...@li... Subject: [Netcommon-developer] Common Logging 2.0 API Reference Documentation Feedback: Log4NetLoggerВ ConstructorВ Best regards, Oleg Ganin Developer ETNA Software www.etnasoft.com <http://www.etnasoft.com/> Tel: +375-29-5447389 Skype: aleh.hanin E-mail: ale...@et... <mailto:ro...@et...> |
|
From: Erich E. <eei...@gm...> - 2010-02-03 11:24:35
|
I just uploaded a fixed archive. Apologies for the inconvenience. The problem was, that I used WinZip on my Vista x64 to zip the files. WinZip by default uses a new ZIP64 file format, that the Windows-ZIP-integration does not know about. -Erich From: Zuleika Aditta (Task Technology) [mailto:za...@ta...] Sent: Thursday, January 28, 2010 2:09 AM To: net...@li... Subject: [Netcommon-developer] Compressed File corrupted Hi , I am trying to download the latest release of Common.Logging component (v2.0.0), the zip file appears to be corrupted when I am trying to uncompressed. I tried older version and it works. Can you check this file in your repository ? I still looking forward to download this component for my development. Thank you very much for your kind assistance. cheers Zuleika Aditta technical consultant e. <mailto:cw...@ta...> za...@ta... The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Whilst we have taken precautions to alert us to the presence of computer viruses, we cannot guarantee that this email and any files transmitted with it are free from such viruses. |
|
From: Oleg G. <ole...@et...> - 2010-02-02 17:20:03
|
Best regards, Oleg Ganin Developer ETNA Software www.etnasoft.com <http://www.etnasoft.com/> Tel: +375-29-5447389 Skype: aleh.hanin E-mail: ale...@et... <mailto:ro...@et...> |
|
From: Zuleika A. (T. Technology) <za...@ta...> - 2010-01-28 01:21:54
|
Hi , I am trying to download the latest release of Common.Logging component (v2.0.0), the zip file appears to be corrupted when I am trying to uncompressed. I tried older version and it works. Can you check this file in your repository ? I still looking forward to download this component for my development. Thank you very much for your kind assistance. cheers Zuleika Aditta technical consultant e. za...@ta... <mailto:cw...@ta...> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Whilst we have taken precautions to alert us to the presence of computer viruses, we cannot guarantee that this email and any files transmitted with it are free from such viruses. |
|
From: Erich E. <eei...@gm...> - 2010-01-22 19:05:00
|
Hi,
you still need to use
log4net.GlobalContext.Properties["BrokerID"] = 10
to set this property, even when using Common.Logging. CL only wraps the log4net API but doesn't implement its own logic. Although in the works, CL does not support vendor-neutral contexts yet.
Put the above line on the entry point of your application, in webapps this usually is Application_Start(), in clientapss put it as first method into Main()
hth,
Erich
From: Kyle LeNeau [mailto:kyl...@te...]
Sent: Friday, January 22, 2010 5:31 PM
To: net...@li...
Subject: [Netcommon-developer] log4net properties in Common.Logging
Does anyone know if there is an equivalent in Common.Logging (for .Net) to set properties for the log4net factory adapter? I have had great success when just using log4net by doing:
<appender name="FileAppender" type="log4net.Appender.RollingFileAppender">
<file type="log4net.Util.PatternString" value="logs\Log_%property{BrokerID}.txt"/>
<appendToFile value="false"/>
<rollingStyle value="Size"/>
<maxSizeRollBackups value="-1"/>
<maximumFileSize value="50GB"/>
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%date %-5level %logger - %message%newline"/>
</layout>
</appender>
and setting the property like:`log4net.GlobalContext.Properties["BrokerID"] = 10`
The file I end up with the looks like this: `Log_(null).txt` when using the common.logging to wire up log4net on the fly.
--
Kyle LeNeau
WhereToLive.com
7695 Anagram Drive
Eden Prairie, MN 55344
Call: 952-294-8080
Fax: 952-294-8181
kyl...@te...
www.WhereToLive.com
|
|
From: Kyle L. <kyl...@te...> - 2010-01-22 16:42:59
|
Does anyone know if there is an equivalent in Common.Logging (for .Net)
to set properties for the log4net factory adapter? I have had great
success when just using log4net by doing:
<appender name="FileAppender" type="log4net.Appender.RollingFileAppender">
<file type="log4net.Util.PatternString"
value="logs\Log_%property{BrokerID}.txt"/>
<appendToFile value="false"/>
<rollingStyle value="Size"/>
<maxSizeRollBackups value="-1"/>
<maximumFileSize value="50GB"/>
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%date %-5level %logger - %message%newline"/>
</layout>
</appender>
and setting the property
like:`log4net.GlobalContext.Properties["BrokerID"] = 10`
The file I end up with the looks like this: `Log_(null).txt` when using
the common.logging to wire up log4net on the fly.
--
Kyle LeNeau
WhereToLive.com
7695 Anagram Drive
Eden Prairie, MN 55344
Call: 952-294-8080
Fax: 952-294-8181
kyl...@te... <mailto:kyl...@te...>
www.WhereToLive.com <http://www.wheretolive.com>
|
|
From: Erich E. <eei...@gm...> - 2009-12-11 12:24:21
|
just tried it, but can't reproduce
compiling and running the code
using Common.Logging;
namespace MainApplication
{
public class Program
{
public static void Main()
{
Common.Logging.LogManager.GetLogger(typeof(Program)).Fatal("this is a debug message");
}
}
}
using your config perfectly results in
2009-12-11 13:14:33,799 [1] FATAL [MainApplication.Program.Main] - this is a debug message
are you sure, the right assemblies are loaded? You can DM me a project that reproduces the pb if you want - would really love to know what's going on.
-Erich
From: Peter A. Kirk [mailto:pk...@al...]
Sent: Thursday, December 10, 2009 9:26 PM
To: net...@li...
Subject: Re: [Netcommon-developer] CommonLogging log4net - Email found in subject
Hi – thanks for your reply.
I am using common-logging version 2.0.0.0
And log4net version 1.2.10.0
The configuration looks like:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="common">
<section name="logging" type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
</sectionGroup>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />
</configSections>
<common>
<logging>
<factoryAdapter type="Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter, Common.Logging.Log4Net">
<arg key="configType" value="INLINE" />
</factoryAdapter>
</logging>
</common>
<log4net>
<appender name="ExampleAppender" type="log4net.Appender.RollingFileAppender">
<file value="./common_logging_logfile.txt" />
<appendToFile value="true" />
<rollingStyle value="Size" />
<maxSizeRollBackups value="100" />
<maximumFileSize value="1000KB" />
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%d [%t] %-5p [%C.%M] - %m%n" />
</layout>
</appender>
<logger name="MainApplication.Program">
<level value="DEBUG" />
<appender-ref ref="ExampleAppender" />
</logger>
</log4net>
</configuration>
Med venlig hilsen / Best regards
Peter Kirk
E-mail: mailto:pk...@al...
From: Erich Eichinger [mailto:eei...@gm...]
Sent: 11. december 2009 01:42
To: Peter A. Kirk; net...@li...
Subject: RE: [Netcommon-developer] CommonLogging log4net - Email found in subject
Hi Peter,
What version of Common.Logging are you using? What version of Log4Net? How does your configuration look like?
tx for pointing me to the email mistake - jus t fixed
-Erich
From: Peter A. Kirk [mailto:pk...@al...]
Sent: Thursday, December 10, 2009 10:13 AM
To: net...@li...
Subject: [Netcommon-developer] CommonLogging log4net
Hi
I am using common-logging and log4net, with a lognet conversion pattern like:
<conversionPattern value="%d [%t] %-5p [%C.%M] - %m%n" />
The %C.%M should display the class.method name of the method doing the logging – and it does, except this is the class
[Common.Logging.Factory.AbstractLogger.Debug], and not the class I am really interested in.
Can I configure it such that it is the name of the class and method calling common-logging which is written to the log?
(BTW, on the this project’s page on sourceforge, the email-address for this project is given as
net...@li...
but I am not sure if this is correct, so I have written to that address and
net...@li...)
Med venlig hilsen / Best regards
Peter Kirk
E-mail: mailto:pk...@al... <mailto:cj...@al...>
|
|
From: Peter A. K. <pk...@al...> - 2009-12-10 20:26:30
|
Hi – thanks for your reply.
I am using common-logging version 2.0.0.0
And log4net version 1.2.10.0
The configuration looks like:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="common">
<section name="logging" type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
</sectionGroup>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />
</configSections>
<common>
<logging>
<factoryAdapter type="Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter, Common.Logging.Log4Net">
<arg key="configType" value="INLINE" />
</factoryAdapter>
</logging>
</common>
<log4net>
<appender name="ExampleAppender" type="log4net.Appender.RollingFileAppender">
<file value="./common_logging_logfile.txt" />
<appendToFile value="true" />
<rollingStyle value="Size" />
<maxSizeRollBackups value="100" />
<maximumFileSize value="1000KB" />
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%d [%t] %-5p [%C.%M] - %m%n" />
</layout>
</appender>
<logger name="MainApplication.Program">
<level value="DEBUG" />
<appender-ref ref="ExampleAppender" />
</logger>
</log4net>
</configuration>
Med venlig hilsen / Best regards
Peter Kirk
E-mail: mailto:pk...@al...
From: Erich Eichinger [mailto:eei...@gm...]
Sent: 11. december 2009 01:42
To: Peter A. Kirk; net...@li...
Subject: RE: [Netcommon-developer] CommonLogging log4net - Email found in subject
Hi Peter,
What version of Common.Logging are you using? What version of Log4Net? How does your configuration look like?
tx for pointing me to the email mistake - jus t fixed
-Erich
From: Peter A. Kirk [mailto:pk...@al...]
Sent: Thursday, December 10, 2009 10:13 AM
To: net...@li...
Subject: [Netcommon-developer] CommonLogging log4net
Hi
I am using common-logging and log4net, with a lognet conversion pattern like:
<conversionPattern value="%d [%t] %-5p [%C.%M] - %m%n" />
The %C.%M should display the class.method name of the method doing the logging – and it does, except this is the class
[Common.Logging.Factory.AbstractLogger.Debug], and not the class I am really interested in.
Can I configure it such that it is the name of the class and method calling common-logging which is written to the log?
(BTW, on the this project’s page on sourceforge, the email-address for this project is given as
net...@li...<mailto:net...@li...>
but I am not sure if this is correct, so I have written to that address and
net...@li...<mailto:net...@li...>)
Med venlig hilsen / Best regards
Peter Kirk
E-mail: mailto:pk...@al...<mailto:cj...@al...>
|
|
From: Erich E. <eei...@gm...> - 2009-12-10 12:42:08
|
Hi Peter, What version of Common.Logging are you using? What version of Log4Net? How does your configuration look like? tx for pointing me to the email mistake - jus t fixed -Erich From: Peter A. Kirk [mailto:pk...@al...] Sent: Thursday, December 10, 2009 10:13 AM To: net...@li... Subject: [Netcommon-developer] CommonLogging log4net Hi I am using common-logging and log4net, with a lognet conversion pattern like: <conversionPattern value="%d [%t] %-5p [%C.%M] - %m%n" /> The %C.%M should display the class.method name of the method doing the logging – and it does, except this is the class [Common.Logging.Factory.AbstractLogger.Debug], and not the class I am really interested in. Can I configure it such that it is the name of the class and method calling common-logging which is written to the log? (BTW, on the this project’s page on sourceforge, the email-address for this project is given as net...@li... but I am not sure if this is correct, so I have written to that address and net...@li...) Med venlig hilsen / Best regards Peter Kirk E-mail: mailto:pk...@al... <mailto:cj...@al...> |
|
From: Peter A. K. <pk...@al...> - 2009-12-10 09:26:04
|
Hi I am using common-logging and log4net, with a lognet conversion pattern like: <conversionPattern value="%d [%t] %-5p [%C.%M] - %m%n" /> The %C.%M should display the class.method name of the method doing the logging - and it does, except this is the class [Common.Logging.Factory.AbstractLogger.Debug], and not the class I am really interested in. Can I configure it such that it is the name of the class and method calling common-logging which is written to the log? (BTW, on the this project's page on sourceforge, the email-address for this project is given as net...@li...<mailto:net...@li...> but I am not sure if this is correct, so I have written to that address and net...@li...<mailto:net...@li...>) Med venlig hilsen / Best regards Peter Kirk E-mail: mailto:pk...@al...<mailto:cj...@al...> |
|
From: Kenneth X. <KX...@bn...> - 2009-04-30 17:55:40
|
Erich, totally understood! I have created the issue in the tracker: https://sourceforge.net/tracker/?func=detail&aid=2784525&group_id=182424&atid=901159 Thanks, Kenneth From: Erich Eichinger [mailto:eei...@gm...] Sent: Thursday, April 30, 2009 12:50 PM To: Kenneth Xu; 'Mark Pollack'; spr...@li... Cc: net...@li... Subject: RE: [Springnet-developer] fyi: nunit 2.5 RC is out Kenneth, sorry those features didn't make it into the release as your request reached me exactly at the time I was about to release CL ;-). Bad timing. Anyway since other requests already dropped in since the release I will set up a public location to offer nightly build downloads until the next release. Please enter your requests + links to your googlcode stuff into the SF tracker (I know it sucks, already looking for alternatives). Also lets move further discussions to the netcommon mailinglist (cc'ed) cheers, Erich From: Kenneth Xu [mailto:KX...@bn...] Sent: Thursday, April 30, 2009 6:21 PM To: Erich Eichinger; Mark Pollack; spr...@li... Subject: RE: [Springnet-developer] fyi: nunit 2.5 RC is out I usually do not use Trace.Debug as Common.Logging is my favorite :) I can certainly give it a try and let you know. BTW, thanks for the quick implementation of the in memory sink in Common.Logging 2.0. Hope I’m not asking too much :) but 1. It would be great if I can set the log level independently on each logger when unit testing 2. How about a separate sink for individual logger? I feel my assert against the log event is much cleaner that way. I did that for 1.2, you can take them if you want to make further modifications for 2.0. From: Erich Eichinger [mailto:eei...@gm...] Sent: Thursday, April 30, 2009 11:47 AM To: Kenneth Xu; 'Mark Pollack'; spr...@li... Subject: RE: [Springnet-developer] fyi: nunit 2.5 RC is out Great! Tx Kenneth for sharing your experience. I recently noticed Ayende complaining in twitter about not seeing any Trace.Debug() messages in DebugView when running NUnit 2.5 and thus switching to xUnit instead. Did you experience any similar issues? -Erich From: Kenneth Xu [mailto:KX...@bn...] Sent: Thursday, April 30, 2009 5:38 PM To: Erich Eichinger; Mark Pollack; spr...@li... Subject: RE: [Springnet-developer] fyi: nunit 2.5 RC is out Mark and Erich, Just to share my experience. I used NUnit 2.5 in the Spring.Data.Extension, which is mainly an extract of our enhancement to Spring working with ODP.Net. The parameterized test cases and generic support are great. TD.Net worked very. Here is an example that uses both generic and parameterized test cases. http://code.google.com/p/kennethxublogsource/source/browse/trunk/SpringExtension/test/Spring.Data.Extension.Tests/Data/Generic/ExtendedRowMapperResultSetExtractorTest.cs Cheers, Kenneth From: Erich Eichinger [mailto:eei...@gm...] Sent: Wednesday, April 29, 2009 10:32 AM To: 'Mark Pollack'; spr...@li... Subject: Re: [Springnet-developer] fyi: nunit 2.5 RC is out Importance: Low TD.NET might detect NUnit extensions already. R#'s implementation of the runner is entirely decoupled from NUnit - they just look for attributes named "TestFixtureAttribute" and "TestAttribute" using reflection and string comparison and use their own testrunner implementation. I don't think R# 4.5 improved this. But think there are alternatives out there, I know for Gallio/MbUnit there are, which might be able to run nunit tests as well. I just need to upgrade the Nunitaspex stuff and we should be done. Although when we upgrade to nunit 2.5 for 1.2.1 we could upgrade logging as well then... - your turn ;-) -Erich From: Mark Pollack [mailto:Mar...@sp...] Sent: Wednesday, April 29, 2009 4:18 PM To: Eric Eichinger; spr...@li... Subject: RE: [Springnet-developer] fyi: nunit 2.5 RC is out Hi, Cool. Sounds like it is time to take a look again at resharper etc., to see if they will detect NUnit extensions so we can get things like the ‘Spring TestContext Framework’ going – (weird name) http://static.springframework.org/spring/docs/2.5.x/reference/testing.html#testcontext-framework Uses attributes instead of inheritance… I implemented a bit of this a long time ago but only the NUnit GUI runner still recognized the test fixture with a [ContextConfiguration] attribute… not Resharper or TestDriven.NET L I don’t see direct support for ordering of tests… still to unit testy focused….. Did I miss something? Mark From: Erich Eichinger [mailto:eei...@gm...] Sent: Wednesday, April 29, 2009 5:22 AM To: spr...@li... Subject: [Springnet-developer] fyi: nunit 2.5 RC is out seems to have some very interesting features including executing threaded tests, parameterized tests and better extensibility: http://tech.groups.yahoo.com/group/altdotnet/message/21599 -Erich __________ Information from ESET NOD32 Antivirus, version of virus signature database 4041 (20090428) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 4041 (20090428) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ------------------------------------------------------------------------- This electronic mail message contains information that (a) is or may be CONFIDENTIAL, PROPRIETARY IN NATURE, OR OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the use of the addressee(s) named herein. If you are not an intended recipient, please send an email immediately to pos...@bn... and take the steps necessary to delete the message completely from your computer system. ------------------------------------------------------------------------- This electronic mail message contains information that (a) is or may be CONFIDENTIAL, PROPRIETARY IN NATURE, OR OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the use of the addressee(s) named herein. If you are not an intended recipient, please send an email immediately to pos...@bn... and take the steps necessary to delete the message completely from your computer system. ------------------------------------------------------------------------- This electronic mail message contains information that (a) is or may be CONFIDENTIAL, PROPRIETARY IN NATURE, OR OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the use of the addressee(s) named herein. If you are not an intended recipient, please send an email immediately to pos...@bn... and take the steps necessary to delete the message completely from your computer system. |
|
From: Erich E. <eei...@gm...> - 2009-04-30 16:50:42
|
Kenneth, sorry those features didn't make it into the release as your request reached me exactly at the time I was about to release CL ;-). Bad timing. Anyway since other requests already dropped in since the release I will set up a public location to offer nightly build downloads until the next release. Please enter your requests + links to your googlcode stuff into the SF tracker (I know it sucks, already looking for alternatives). Also lets move further discussions to the netcommon mailinglist (cc'ed) cheers, Erich From: Kenneth Xu [mailto:KX...@bn...] Sent: Thursday, April 30, 2009 6:21 PM To: Erich Eichinger; Mark Pollack; spr...@li... Subject: RE: [Springnet-developer] fyi: nunit 2.5 RC is out I usually do not use Trace.Debug as Common.Logging is my favorite :) I can certainly give it a try and let you know. BTW, thanks for the quick implementation of the in memory sink in Common.Logging 2.0. Hope I’m not asking too much :) but 1. It would be great if I can set the log level independently on each logger when unit testing 2. How about a separate sink for individual logger? I feel my assert against the log event is much cleaner that way. I did that for 1.2, you can take them if you want to make further modifications for 2.0. From: Erich Eichinger [mailto:eei...@gm...] Sent: Thursday, April 30, 2009 11:47 AM To: Kenneth Xu; 'Mark Pollack'; spr...@li... Subject: RE: [Springnet-developer] fyi: nunit 2.5 RC is out Great! Tx Kenneth for sharing your experience. I recently noticed Ayende complaining in twitter about not seeing any Trace.Debug() messages in DebugView when running NUnit 2.5 and thus switching to xUnit instead. Did you experience any similar issues? -Erich From: Kenneth Xu [mailto:KX...@bn...] Sent: Thursday, April 30, 2009 5:38 PM To: Erich Eichinger; Mark Pollack; spr...@li... Subject: RE: [Springnet-developer] fyi: nunit 2.5 RC is out Mark and Erich, Just to share my experience. I used NUnit 2.5 in the Spring.Data.Extension, which is mainly an extract of our enhancement to Spring working with ODP.Net. The parameterized test cases and generic support are great. TD.Net worked very. Here is an example that uses both generic and parameterized test cases. http://code.google.com/p/kennethxublogsource/source/browse/trunk/SpringExtension/test/Spring.Data.Extension.Tests/Data/Generic/ExtendedRowMapperResultSetExtractorTest.cs Cheers, Kenneth From: Erich Eichinger [mailto:eei...@gm...] Sent: Wednesday, April 29, 2009 10:32 AM To: 'Mark Pollack'; spr...@li... Subject: Re: [Springnet-developer] fyi: nunit 2.5 RC is out Importance: Low TD.NET might detect NUnit extensions already. R#'s implementation of the runner is entirely decoupled from NUnit - they just look for attributes named "TestFixtureAttribute" and "TestAttribute" using reflection and string comparison and use their own testrunner implementation. I don't think R# 4.5 improved this. But think there are alternatives out there, I know for Gallio/MbUnit there are, which might be able to run nunit tests as well. I just need to upgrade the Nunitaspex stuff and we should be done. Although when we upgrade to nunit 2.5 for 1.2.1 we could upgrade logging as well then... - your turn ;-) -Erich From: Mark Pollack [mailto:Mar...@sp...] Sent: Wednesday, April 29, 2009 4:18 PM To: Eric Eichinger; spr...@li... Subject: RE: [Springnet-developer] fyi: nunit 2.5 RC is out Hi, Cool. Sounds like it is time to take a look again at resharper etc., to see if they will detect NUnit extensions so we can get things like the ‘Spring TestContext Framework’ going – (weird name) http://static.springframework.org/spring/docs/2.5.x/reference/testing.html#testcontext-framework Uses attributes instead of inheritance… I implemented a bit of this a long time ago but only the NUnit GUI runner still recognized the test fixture with a [ContextConfiguration] attribute… not Resharper or TestDriven.NET L I don’t see direct support for ordering of tests… still to unit testy focused….. Did I miss something? Mark From: Erich Eichinger [mailto:eei...@gm...] Sent: Wednesday, April 29, 2009 5:22 AM To: spr...@li... Subject: [Springnet-developer] fyi: nunit 2.5 RC is out seems to have some very interesting features including executing threaded tests, parameterized tests and better extensibility: http://tech.groups.yahoo.com/group/altdotnet/message/21599 -Erich __________ Information from ESET NOD32 Antivirus, version of virus signature database 4041 (20090428) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 4041 (20090428) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ------------------------------------------------------------------------- This electronic mail message contains information that (a) is or may be CONFIDENTIAL, PROPRIETARY IN NATURE, OR OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the use of the addressee(s) named herein. If you are not an intended recipient, please send an email immediately to pos...@bn... and take the steps necessary to delete the message completely from your computer system. ------------------------------------------------------------------------- This electronic mail message contains information that (a) is or may be CONFIDENTIAL, PROPRIETARY IN NATURE, OR OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the use of the addressee(s) named herein. If you are not an intended recipient, please send an email immediately to pos...@bn... and take the steps necessary to delete the message completely from your computer system. |
|
From: Kenneth Xu <ken...@gm...> - 2009-04-27 04:40:40
|
Great Job! Kenneth Xu Account Manager Tel: 917-817-6135 Fax: 917-536-9789 Sharneng International Group, Inc. On Sun, Apr 26, 2009 at 5:25 PM, Erich Eichinger <eei...@gm...>wrote: > Hi Everyone, > > > > I just released Common.Logging 2.0 - you can pick it up at > http://sourceforge.net/project/showfiles.php?group_id=182424 > > > > The reference documentation can be found at > http://netcommon.sourceforge.net/docs/2.0.0/reference/html/index.html > > The new SDK documentation is here: > http://netcommon.sourceforge.net/docs/2.0.0/api/html/index.html > > > > There is a whole bunch of new features, bridging between all supported > logging libraries, an extended ILog interface for convenient usage, base > classes for implementing your own adapters and performance improvements > (checkout my blog at > http://eeichinger.blogspot.com/2009/01/thoughts-on-systemdiagnostics-trace-vs.html) > ! > > > > Here's the complete list: > > > > Common.Logging CHANGELOG > > ===================================== > > http://netcommon.sf.net > > > > Release 2.0.0, April 26 2009 > > > > Summary: New Features and Bug Fix release > > > > IMPORTANT NOTE: > > starting with version 2.0 we dropped support for .NET versions 1.0 and 1.1. > - if you need support > > for those platforms please download Common.Logging 1.2 > > > > Breaking Changes > > *) LogManager.ConfigurationReader is readonly now -> use LogManager.Reset() > instead > > > > Feature Requests > > > > [2781806] - routing from 3rd party lib back to Common.Logging > > [2778784] - Add In-Memory > LoggerFactoryAdapter->CapturingLoggerFactoryAdapter > > [2485203] - Add support for EntLib 4.1 logging > > [2512017] - Provide base classes for implementing custom factoryAdapters > > [1810787] - Add source code to distribution > > [1826632] - Make Common.Logging ClsCompliant > > [1970386] - Support for Enterprise Library 4.0 > > [1852882] - Add optimize flag + PdbOnly in release build > > [1847554] - Add TraceListener to capture Diagnostics.Trace calls > > [1710163] - Add xxxFormat methods to Common.Logging.ILog interface > > [2545123] - Add LogManager.GetCurrentClassLogger() > > [1810785] - Clean up code comments > > > > Bug Fixes > > > > [1683776] - Implementations of ILog are not serializable > > [1683773] - Add log4net 1.2.9 .dll to distribution for .NET 1.0 > > [1683772] - Null Pointer Exception when passing in null value for msg > > [1683774] - Add unit tests for Common.Logging > > [1846258] - ConfigurationSectionHandler not case-insensitive in NET 2.0 > > > > > > It's late, will update the website tomorrow... > > > > enjoy, > > Erich > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensign option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Netcommon-developer mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netcommon-developer > > |
|
From: Erich E. <eei...@gm...> - 2009-04-26 21:25:58
|
Hi Everyone, I just released Common.Logging 2.0 - you can pick it up at http://sourceforge.net/project/showfiles.php?group_id=182424 The reference documentation can be found at http://netcommon.sourceforge.net/docs/2.0.0/reference/html/index.html The new SDK documentation is here: http://netcommon.sourceforge.net/docs/2.0.0/api/html/index.html There is a whole bunch of new features, bridging between all supported logging libraries, an extended ILog interface for convenient usage, base classes for implementing your own adapters and performance improvements (checkout my blog at http://eeichinger.blogspot.com/2009/01/thoughts-on-systemdiagnostics-trace-v s.html) ! Here's the complete list: Common.Logging CHANGELOG ===================================== http://netcommon.sf.net Release 2.0.0, April 26 2009 Summary: New Features and Bug Fix release IMPORTANT NOTE: starting with version 2.0 we dropped support for .NET versions 1.0 and 1.1. - if you need support for those platforms please download Common.Logging 1.2 Breaking Changes *) LogManager.ConfigurationReader is readonly now -> use LogManager.Reset() instead Feature Requests [2781806] - routing from 3rd party lib back to Common.Logging [2778784] - Add In-Memory LoggerFactoryAdapter->CapturingLoggerFactoryAdapter [2485203] - Add support for EntLib 4.1 logging [2512017] - Provide base classes for implementing custom factoryAdapters [1810787] - Add source code to distribution [1826632] - Make Common.Logging ClsCompliant [1970386] - Support for Enterprise Library 4.0 [1852882] - Add optimize flag + PdbOnly in release build [1847554] - Add TraceListener to capture Diagnostics.Trace calls [1710163] - Add xxxFormat methods to Common.Logging.ILog interface [2545123] - Add LogManager.GetCurrentClassLogger() [1810785] - Clean up code comments Bug Fixes [1683776] - Implementations of ILog are not serializable [1683773] - Add log4net 1.2.9 .dll to distribution for .NET 1.0 [1683772] - Null Pointer Exception when passing in null value for msg [1683774] - Add unit tests for Common.Logging [1846258] - ConfigurationSectionHandler not case-insensitive in NET 2.0 It's late, will update the website tomorrow... enjoy, Erich |
|
From: Erich E. <eei...@gm...> - 2009-01-29 09:20:05
|
Hi Jörg, I agree w/ Mark here. Although I enjoyed kicking him *bg* Common.Logging is especially designed to be slim and fast. It even makes sense to use Common.Logging in the case you never intend to switch your target logging system because of a) reduced performance costs and b) a new logging feature leveraging lambda expression to help you avoid sideeffects. I recently published a blog post with my performance test results (http://eeichinger.blogspot.com/2009/01/thoughts-on-systemdiagnostics-trace- vs.html). Having said that, introducing an event that gets fired every time a message is logged is not within the responsibilities the framework is designed for. But, as Mark mentioned, you can always write a FactoryAdapter decorator, that hands out decorated ILog instances to intercept logging calls. You don't even need AOP for this, it is quite straight forward to handcode such a decorator yourself. let me know if I can be of any help! cheers, Erich From: Mark Pollack [mailto:Mar...@sp...] Sent: Samstag, 24. Jänner 2009 18:20 To: Jörg Metzler; net...@li... Subject: Re: [Netcommon-developer] According to Request ID 2514434: Add LoggingMessage- and LogMessage-Event to LogManager Hi, At first glance, Im not very keen to add this feature, but Id like to hear others opinions. The goal of this project is portable logging and this sounds like a new top level feature, unique to common logging, so Id vote -1. I was pulled kicking and screaming to add string format support to the API in 2.0 just to put it in perspective. As Im sure you know, logging implementations usually take care of by providing a plug-in point via logging adapters for the database, messaging, etc. This is a provider specific solution, but that would be the way to go if you want to accurately tie into the underlying logging trail. The logging subsystem is actually responsible for creating the final log output which usually gets stuff appended to the base string that is set as a user for example nested diagnostic context in log4net. If the requirement here is essentially a log viewer/analyzer, that seem natural, if it is more business focused, Id treat it as a first class problem to be solved via some oo-design and not to piggy-back on top of the logger infrastructure. The third way would be to create your own LogManager that returns ILog instances wrapped in an AOP proxy. Then you can apply whatever behavior you like to the ILog interface methods. Cheers, Mark From: Jörg Metzler [mailto:joe...@we...] Sent: Saturday, January 24, 2009 5:30 AM To: net...@li... Subject: [Netcommon-developer] According to Request ID 2514434: Add LoggingMessage- and LogMessage-Event to LogManager Von: Jörg Metzler [mailto:joe...@we...] Gesendet: Dienstag, 20. Januar 2009 22:04 An: 'net...@li...' Betreff: According to Request ID 2514434: Add LoggingMessage- and LogMessage-Event to LogManager Hello, I just downloaded the code for Common.Logging and modified it a bit. I added an event that is fired, everytime a log-method is called. Why? I want to show some of the log message in a WindowsForms ListBox or something like that. One possibility was to create a super uber special ILoggerFactoryAdapter and cast the LogManager.Adapter to this in my application. This sucks and is the root of all evil, because I cant change the implementation. Additionally the implementation of the logging should not influence my app. So whats new? The LogManager has two new Properties: - LogMessage (event) New Files: - LogMessageEventArgs.cs - Internal\InternalLog.cs - Internal\InternalLoggerFactoryAdapter.cs - Internal\LogMessageCallback.cs - Internal\NeedsCallLogMessageCallback.cs Could you add this in your next release or is it bullshit what I coded? :-) Please let me know. Jörg Metzler |
|
From: Mark P. <Mar...@sp...> - 2009-01-24 17:20:14
|
Hi, At first glance, I'm not very keen to add this feature, but I'd like to hear others opinions. The goal of this project is portable logging and this sounds like a new top level feature, unique to common logging, so I'd vote -1. I was pulled kicking and screaming to add string format support to the API in 2.0 just to put it in perspective. As I'm sure you know, logging implementations usually take care of by providing a plug-in point via logging adapters for the database, messaging, etc. This is a provider specific solution, but that would be the way to go if you want to accurately tie into the underlying logging trail. The logging subsystem is actually responsible for creating the final log output - which usually gets stuff appended to the 'base string' that is set as a user - for example nested diagnostic context in log4net. If the requirement here is essentially a log viewer/analyzer, that seem natural, if it is more business focused, I'd treat it as a first class problem to be solved via some oo-design and not to piggy-back on top of the logger infrastructure. The 'third way' would be to create your own LogManager that returns ILog instances wrapped in an AOP proxy. Then you can apply whatever behavior you like to the ILog interface methods. Cheers, Mark From: Jörg Metzler [mailto:joe...@we...] Sent: Saturday, January 24, 2009 5:30 AM To: net...@li... Subject: [Netcommon-developer] According to Request ID 2514434: Add LoggingMessage- and LogMessage-Event to LogManager Von: Jörg Metzler [mailto:joe...@we...] Gesendet: Dienstag, 20. Januar 2009 22:04 An: 'net...@li...' Betreff: According to Request ID 2514434: Add LoggingMessage- and LogMessage-Event to LogManager Hello, I just downloaded the code for Common.Logging and modified it a bit. I added an event that is fired, everytime a log-method is called. Why? I want to show some of the log message in a WindowsForms ListBox or something like that. One possibility was to create a super uber special ILoggerFactoryAdapter and cast the LogManager.Adapter to this in my application. This sucks and is the root of all evil, because I can't change the implementation. Additionally the implementation of the logging should not influence my app. So what's new? The LogManager has two new Properties: - LogMessage (event) New Files: - LogMessageEventArgs.cs - Internal\InternalLog.cs - Internal\InternalLoggerFactoryAdapter.cs - Internal\LogMessageCallback.cs - Internal\NeedsCallLogMessageCallback.cs Could you add this in your next release or is it bullshit what I coded? :-) Please let me know. Jörg Metzler |
|
From: Peter A. K. <pk...@al...> - 2009-01-16 08:58:06
|
Thanks a lot for that, guys! With your new common.logging.dll I can get my app to work with EntLib 4.1 and with Spring.net 1.1.2 (with an assembly redirection). /Peter > -----Original Message----- > From: Erich Eichinger [mailto:eei...@gm...] > Sent: 16. januar 2009 02:45 > To: net...@li... > Subject: [Netcommon-developer] Common.Logging v2.0 preview > ready for download > > The signed preview build for the upcoming version 2.0 of > Common.Logging is > ready for download at > > <http://www.springframework.net/downloads/netcommon/> > > What's new? > ----------- > - added support for EntLib 4.1 logging > - extended ILog interface now includes XXXFormat( string > format, params > object[] args ) signatures > - leveraging lambdas, the ILog interface offers a new & safe > way to write > log statements: > > log.Debug( m=>m("value= {0}", obj.Value) ); > > this ensures, that the whole expression is only evaluated when > LogLevel.Debug is enabled and thus saves > you from writing > > if (log.IsDebugEnabled) > { > log.Debug("value={0}", obj.Value); > } > > to avoid this overhead. > > > Upgrading > --------- > All that's necessary for upgrading from 1.2 is copy the new > assemblies in > place and specifying a version redirect. Recompiling your > application of > course links your app to the new version w/o a redirect. > 2.0 runtime (Common.Logging.dll) is fully binary backwards compatible. > > Note to implementors of the ILog interface: Due to the > extensions, you need > to extend your implementations as well. As an added benefit, > 2.0 comes with > some convenience classes, making it easy to implement your > own log system > integration. Check out AbstractLogger and > AbstractSimpleLogger for more > information. > > > Spring.NET > ---------- > I removed the dependency of Spring and it's SPI > implementation of ILog for > testing purposes, thus compiling & testing the codebase > against the new > version is no issue anymore starting with the next nightly build of > Spring.NET > > Give the new version a whirl and please send your feedback! > > enjoy, > Erich > > > > -------------------------------------------------------------- > ---------------- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Netcommon-developer mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netcommon-developer > |
|
From: Erich E. <eei...@gm...> - 2009-01-16 02:47:05
|
The signed preview build for the upcoming version 2.0 of Common.Logging is ready for download at <http://www.springframework.net/downloads/netcommon/> What's new? ----------- - added support for EntLib 4.1 logging - extended ILog interface now includes XXXFormat( string format, params object[] args ) signatures - leveraging lambdas, the ILog interface offers a new & safe way to write log statements: log.Debug( m=>m("value= {0}", obj.Value) ); this ensures, that the whole expression is only evaluated when LogLevel.Debug is enabled and thus saves you from writing if (log.IsDebugEnabled) { log.Debug("value={0}", obj.Value); } to avoid this overhead. Upgrading --------- All that's necessary for upgrading from 1.2 is copy the new assemblies in place and specifying a version redirect. Recompiling your application of course links your app to the new version w/o a redirect. 2.0 runtime (Common.Logging.dll) is fully binary backwards compatible. Note to implementors of the ILog interface: Due to the extensions, you need to extend your implementations as well. As an added benefit, 2.0 comes with some convenience classes, making it easy to implement your own log system integration. Check out AbstractLogger and AbstractSimpleLogger for more information. Spring.NET ---------- I removed the dependency of Spring and it's SPI implementation of ILog for testing purposes, thus compiling & testing the codebase against the new version is no issue anymore starting with the next nightly build of Spring.NET Give the new version a whirl and please send your feedback! enjoy, Erich |
1 message has been excluded from this view by a project administrator.
