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: Jeffrey B. <jef...@gm...> - 2012-01-10 19:50:51
|
I'm not sure if anyone on this list is responsible for the NuGet packages for Common.Logging but the developers are not contactable through the NuGet form. The Common.Logging.Log4Net package is currently broken. Specifically the package is configured to require log4net >= 1.2.10 which will cause nuget to install the latest log4net (1.2.11) even if 1.2.10 is already installed. I was able to fix the issue temporarily using a bindingRedirection in my app.config. However, I've put a large amount of effort into eliminating my need for app.config and would like to be able to go back to deploying without one. |
|
From: Harman, D. A <dan...@jp...> - 2012-01-10 16:00:20
|
Not sure, but possibly under more active development? Kind regards Daniel A Harman | VP | Delta1/PT RAD | J.P. Morgan | 10 Aldermanbury, London, EC2V 7RF | T: +44 (0) 207 742 6565 | F: +44 (0)207 325 3722 | dan...@jp... | jpmorgan.com From: Bruno Baia [mailto:br...@gm...] Sent: 10 January 2012 15:16 To: Harman, Daniel A Cc: as...@sz...; net...@li... Subject: Re: [Netcommon-developer] log4net Version=1.2.11.0 Looks like a copy/paste from Common Logging - Bruno 2012/1/10 Harman, Daniel A <dan...@jp...<mailto:dan...@jp...>> It's worth noting that servicestack now have a similar logging abstraction component. Not tried it yet, but may be worth consideration. Kind regards Daniel A Harman | VP | Delta1/PT RAD | J.P. Morgan | 10 Aldermanbury, London, EC2V 7RF | T: +44 (0) 207 742 6565<tel:%2B44%20%280%29%20207%20742%206565> | F: +44 (0)207 325 3722<tel:%2B44%20%280%29207%20325%203722> | dan...@jp...<mailto:dan...@jp...> | jpmorgan.com<http://jpmorgan.com> -----Original Message----- From: as...@sz...<mailto:as...@sz...> [mailto:as...@sz...<mailto:as...@sz...>] Sent: 10 January 2012 13:52 To: net...@li...<mailto:net...@li...> Subject: [Netcommon-developer] log4net Version=1.2.11.0 Dear Team, I would like to use log4net 1.2.11, but the SpecificVersion is true in the Common.Logging.Log4Net.2008.csproj file. Can you issue a new version with SpecificVersion is false? Thanks a lot, Attila. ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join<http://appdeveloper.intel.com/join> http://p.sf.net/sfu/intel-appdev _______________________________________________ Netcommon-developer mailing list Net...@li...<mailto:Net...@li...> https://lists.sourceforge.net/lists/listinfo/netcommon-developer This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join<http://appdeveloper.intel.com/join> http://p.sf.net/sfu/intel-appdev _______________________________________________ Netcommon-developer mailing list Net...@li...<mailto:Net...@li...> https://lists.sourceforge.net/lists/listinfo/netcommon-developer |
|
From: <as...@sz...> - 2012-01-10 15:58:58
|
Hi,
Thaks your reply, I tried it:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="log4net"
publicKeyToken="1b44e1d426115821" culture="neutral" />
<bindingRedirect oldVersion="1.2.10.0" newVersion="1.2.11.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
it was OK, but the XmlConfigurator.ConfigureAndWatch of log4net 1.2.10
is not compatible with 1.2.11, thus I must rewrite my code too.
System.MissingMethodException:
Method not found:
'Void log4net.Config.XmlConfigurator.ConfigureAndWatch(System.IO.FileInfo)'.
Attila.
Idézet (Bruno Baia <br...@gm...>):
> Hi,
>
> Use binding redirection:
> http://msdn.microsoft.com/en-us/library/eftw1fys.aspx
>
>
> - Bruno
>
> 2012/1/10 <as...@sz...>
>
>> Dear Team,
>>
>> I would like to use log4net 1.2.11, but the SpecificVersion is true in
>> the Common.Logging.Log4Net.2008.csproj file.
>>
>> Can you issue a new version with SpecificVersion is false?
>>
>> Thanks a lot,
>> Attila.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Write once. Port to many.
>> Get the SDK and tools to simplify cross-platform app development. Create
>> new or port existing apps to sell to consumers worldwide. Explore the
>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>> http://p.sf.net/sfu/intel-appdev
>> _______________________________________________
>> Netcommon-developer mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>>
>
|
|
From: Bruno B. <br...@gm...> - 2012-01-10 15:16:13
|
Looks like a copy/paste from Common Logging - Bruno 2012/1/10 Harman, Daniel A <dan...@jp...> > It's worth noting that servicestack now have a similar logging abstraction > component. Not tried it yet, but may be worth consideration. > > Kind regards > > Daniel A Harman | VP | Delta1/PT RAD | J.P. Morgan | 10 Aldermanbury, > London, EC2V 7RF | T: +44 (0) 207 742 6565 | F: +44 (0)207 325 3722 | > dan...@jp... | jpmorgan.com > > -----Original Message----- > From: as...@sz... [mailto:as...@sz...] > Sent: 10 January 2012 13:52 > To: net...@li... > Subject: [Netcommon-developer] log4net Version=1.2.11.0 > > Dear Team, > > I would like to use log4net 1.2.11, but the SpecificVersion is true in > the Common.Logging.Log4Net.2008.csproj file. > > Can you issue a new version with SpecificVersion is false? > > Thanks a lot, > Attila. > > > > > ------------------------------------------------------------------------------ > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > _______________________________________________ > Netcommon-developer mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netcommon-developer > This email is confidential and subject to important disclaimers and > conditions including on offers for the purchase or sale of > securities, accuracy and completeness of information, viruses, > confidentiality, legal privilege, and legal entity disclaimers, > available at http://www.jpmorgan.com/pages/disclosures/email. > > > ------------------------------------------------------------------------------ > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > _______________________________________________ > Netcommon-developer mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netcommon-developer > |
|
From: Harman, D. A <dan...@jp...> - 2012-01-10 15:07:01
|
It's worth noting that servicestack now have a similar logging abstraction component. Not tried it yet, but may be worth consideration. Kind regards Daniel A Harman | VP | Delta1/PT RAD | J.P. Morgan | 10 Aldermanbury, London, EC2V 7RF | T: +44 (0) 207 742 6565 | F: +44 (0)207 325 3722 | dan...@jp... | jpmorgan.com -----Original Message----- From: as...@sz... [mailto:as...@sz...] Sent: 10 January 2012 13:52 To: net...@li... Subject: [Netcommon-developer] log4net Version=1.2.11.0 Dear Team, I would like to use log4net 1.2.11, but the SpecificVersion is true in the Common.Logging.Log4Net.2008.csproj file. Can you issue a new version with SpecificVersion is false? Thanks a lot, Attila. ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Netcommon-developer mailing list Net...@li... https://lists.sourceforge.net/lists/listinfo/netcommon-developer This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. |
|
From: Bruno B. <br...@gm...> - 2012-01-10 13:55:32
|
Hi, Use binding redirection: http://msdn.microsoft.com/en-us/library/eftw1fys.aspx - Bruno 2012/1/10 <as...@sz...> > Dear Team, > > I would like to use log4net 1.2.11, but the SpecificVersion is true in > the Common.Logging.Log4Net.2008.csproj file. > > Can you issue a new version with SpecificVersion is false? > > Thanks a lot, > Attila. > > > > > ------------------------------------------------------------------------------ > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > _______________________________________________ > Netcommon-developer mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netcommon-developer > |
|
From: <as...@sz...> - 2012-01-10 13:52:18
|
Dear Team, I would like to use log4net 1.2.11, but the SpecificVersion is true in the Common.Logging.Log4Net.2008.csproj file. Can you issue a new version with SpecificVersion is false? Thanks a lot, Attila. |
|
From: Matthew A. <ma...@ma...> - 2011-10-14 19:32:32
|
Nah. I've moved on, back to a Java gig. Thanks, though. On Fri, Oct 14, 2011 at 10:20 AM, Kenneth Xu <ke...@ho...> wrote: > This is a bit late response but have you tried assembly redirect? > > On Mon, Sep 26, 2011 at 12:11 PM, Isabelle Melnick <ime...@ho...> > wrote: >> >> Hi >> >> are there any plans to support Enterprise Library V5 for Common Logging ? >> >> Regards, >> >> ________________________________ >> Isabelle Melnick >> ime...@ho... >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2dcopy1 >> _______________________________________________ >> Netcommon-developer mailing list >> Net...@li... >> https://lists.sourceforge.net/lists/listinfo/netcommon-developer >> > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > Netcommon-developer mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netcommon-developer > > -- @matthewadams12 mailto:ma...@ma... skype:matthewadams12 yahoo:matthewadams aol:matthewadams12 google-talk:mat...@gm... msn:ma...@ma... http://matthewadams.me http://www.linkedin.com/in/matthewadams |
|
From: Kenneth Xu <ke...@ho...> - 2011-10-14 15:21:03
|
This is a bit late response but have you tried assembly redirect? On Mon, Sep 26, 2011 at 12:11 PM, Isabelle Melnick <ime...@ho...>wrote: > Hi > > are there any plans to support Enterprise Library V5 for Common Logging ? > > Regards, > > ------------------------------ > *Isabelle Melnick* > *ime...@ho... * > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Netcommon-developer mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netcommon-developer > > |
|
From: Isabelle M. <ime...@ho...> - 2011-09-26 16:11:58
|
Hi are there any plans to support Enterprise Library V5 for Common Logging ? Regards, Isabelle Melnick ime...@ho... |
|
From: Kenneth Xu <ke...@ho...> - 2011-08-02 20:39:25
|
Hi Mark, That's good news. NUnit moved from SF to github and I believe Charlie was happy with the result. Actually, I'm the one should say thanks as I have been using the Common.Logging all the time. And I'm always glad that I can help. For the issue No.2 I have mentioned. I have opened a bug ticket and provided a suggestion to fix the issue without physically duplicating the source code. There are also links pointing to my implementation of NLog2 logger. BTW, do you have any plan to move Spring.Threading forward? Cheers, Kenneth On Mon, Aug 1, 2011 at 5:40 PM, Mark Pollack <mpo...@vm...> wrote: > Hi Kenneth!**** > > ** ** > > We are going to move the code, etc to github…then all this should be a bit > easier to manager.. .thanks tons for the feedback and fix for bridging!*** > * > > ** ** > > Mark**** > > ** ** > > ** ** > > *From:* Kenneth Xu [mailto:ke...@ho...] > *Sent:* Monday, August 01, 2011 4:00 PM > *To:* net...@li..." > *Subject:* [Netcommon-developer] Common.Logging and NLog**** > > ** ** > > Since there were some talk about NLog and Common.Logging. I'd try to do a > summary on this topic. > > 1. Current adapter still works with NLog2 as good as it is with NLog1. But > it seems that many users are not aware of this. It would be helpful if there > is some documentation, e.g. Q&A on the website to explain this. Below quoted > a comment from > http://stackoverflow.com/questions/6778233/are-there-any-alternatives-to-common-logging > **** > > I still think that if the Common.Logging team want to make people use their > project that a few updates to the website at least might be good - for > example documenting the assembly redirect. Just because the code is stable > and not changing, it doesn't mean the website should be static too.**** > > > 2. Current NLogLogger in CommonLogging 2.0 has an major issue, the issue > was introduced when AbstractLogger was add in CommonLogging 2.0. The change > triggered a bug in NLog (http://nlog.codeplex.com/workitem/6350, please go > vote up) so that the NLog failed to detect the user stack frame for the log > messages sent from CommonLogging. > > 3. There was a proposed work around to problem 2 in > https://sourceforge.net/tracker/?func=detail&aid=3379373&group_id=182424&atid=901159, > but the approach suggested was a hack. The simplest workaround to this > problem is moving all the method from AbstractLogger to NLogLogger. (BTW, it > seems that there is no way for me to add any comment to that ticket) > > 4. I couldn't get CommonLoggingTarget working to bridge NLog messages, I > have created a bug and provided the fix: > https://sourceforge.net/tracker/?func=detail&aid=3382918&group_id=182424&atid=901156 > > Cheers, > Kenneth**** > |
|
From: Mark P. <mpo...@vm...> - 2011-08-01 21:40:51
|
Hi Kenneth! We are going to move the code, etc to github…then all this should be a bit easier to manager.. .thanks tons for the feedback and fix for bridging! Mark From: Kenneth Xu [mailto:ke...@ho...] Sent: Monday, August 01, 2011 4:00 PM To: net...@li..." Subject: [Netcommon-developer] Common.Logging and NLog Since there were some talk about NLog and Common.Logging. I'd try to do a summary on this topic. 1. Current adapter still works with NLog2 as good as it is with NLog1. But it seems that many users are not aware of this. It would be helpful if there is some documentation, e.g. Q&A on the website to explain this. Below quoted a comment from http://stackoverflow.com/questions/6778233/are-there-any-alternatives-to-common-logging I still think that if the Common.Logging team want to make people use their project that a few updates to the website at least might be good - for example documenting the assembly redirect. Just because the code is stable and not changing, it doesn't mean the website should be static too. 2. Current NLogLogger in CommonLogging 2.0 has an major issue, the issue was introduced when AbstractLogger was add in CommonLogging 2.0. The change triggered a bug in NLog (http://nlog.codeplex.com/workitem/6350, please go vote up) so that the NLog failed to detect the user stack frame for the log messages sent from CommonLogging. 3. There was a proposed work around to problem 2 in https://sourceforge.net/tracker/?func=detail <https://sourceforge.net/tracker/?func=detail&aid=3379373&group_id=182424&atid=901159> &aid=3379373&group_id=182424&atid=901159, but the approach suggested was a hack. The simplest workaround to this problem is moving all the method from AbstractLogger to NLogLogger. (BTW, it seems that there is no way for me to add any comment to that ticket) 4. I couldn't get CommonLoggingTarget working to bridge NLog messages, I have created a bug and provided the fix: https://sourceforge.net/tracker/?func=detail <https://sourceforge.net/tracker/?func=detail&aid=3382918&group_id=182424&atid=901156> &aid=3382918&group_id=182424&atid=901156 Cheers, Kenneth |
|
From: Kenneth Xu <ke...@ho...> - 2011-08-01 20:00:44
|
Since there were some talk about NLog and Common.Logging. I'd try to do a summary on this topic. 1. Current adapter still works with NLog2 as good as it is with NLog1. But it seems that many users are not aware of this. It would be helpful if there is some documentation, e.g. Q&A on the website to explain this. Below quoted a comment from http://stackoverflow.com/questions/6778233/are-there-any-alternatives-to-common-logging I still think that if the Common.Logging team want to make people use their > project that a few updates to the website at least might be good - for > example documenting the assembly redirect. Just because the code is stable > and not changing, it doesn't mean the website should be static too. 2. Current NLogLogger in CommonLogging 2.0 has an major issue, the issue was introduced when AbstractLogger was add in CommonLogging 2.0. The change triggered a bug in NLog (http://nlog.codeplex.com/workitem/6350, please go vote up) so that the NLog failed to detect the user stack frame for the log messages sent from CommonLogging. 3. There was a proposed work around to problem 2 in https://sourceforge.net/tracker/?func=detail&aid=3379373&group_id=182424&atid=901159, but the approach suggested was a hack. The simplest workaround to this problem is moving all the method from AbstractLogger to NLogLogger. (BTW, it seems that there is no way for me to add any comment to that ticket) 4. I couldn't get CommonLoggingTarget working to bridge NLog messages, I have created a bug and provided the fix: https://sourceforge.net/tracker/?func=detail&aid=3382918&group_id=182424&atid=901156 Cheers, Kenneth |
|
From: Harman, D. A <dan...@jp...> - 2011-08-01 13:28:22
|
Hi Kenneth, Thanks for that. Kind regards Daniel A Harman | VP | Delta1/PT RAD | J.P. Morgan | 10 Aldermanbury, London, EC2V 7RF | T: +44 (0) 207 742 6565 | F: +44 (0)207 325 3722 | dan...@jp... | jpmorgan.com From: ken...@gm... [mailto:ken...@gm...] On Behalf Of Kenneth Xu Sent: 29 July 2011 17:13 To: Harman, Daniel A Cc: Erich Eichinger; net...@li... Subject: Re: [Netcommon-developer] Status of Common.Logging Hi Danial, I have provided an answer to the 2nd link. For sending logs to NLog, CommonLogging works well with NLog2. All you need to do is to add assembly redirect in your app.config or web.config. HTH, Kenneth On Mon, Jul 25, 2011 at 12:11 PM, Harman, Daniel A <dan...@jp...<mailto:dan...@jp...>> wrote: Hi Erich, The two posts in question are: http://stackoverflow.com/questions/6778233/are-there-any-alternatives-to-common-logging and http://stackoverflow.com/questions/6027997/can-nlog-v2-be-used-with-common-logging (which mentions a problem using nlog2). This is the eternal curse of open source, everyone wants the products, but finding time to contribute is not easy! I will take a look if some time frees up, but I don't realistically think I can contribute at the moment. Is there a new code repository? When I browsed the source forge one, I couldn't spot the nuget packaging scripts one normally sees with nuget packages, which made me wonder if it had been forked. Kind regards Daniel A Harman | VP | Delta1/PT RAD | J.P. Morgan | 10 Aldermanbury, London, EC2V 7RF | T: +44 (0) 207 742 6565<tel:%2B44%20%280%29%20207%20742%206565> | F: +44 (0)207 325 3722<tel:%2B44%20%280%29207%20325%203722> | dan...@jp...<mailto:dan...@jp...> | jpmorgan.com<http://jpmorgan.com> From: Erich Eichinger [mailto:eei...@gm...<mailto:eei...@gm...>] Sent: 25 July 2011 15:04 To: Harman, Daniel A Cc: net...@li...<mailto:net...@li...> Subject: Re: [Netcommon-developer] Status of Common.Logging Dan, yes, this project is still alive. Admittedly it could need the help of some contributors though! What StackOverflow post are you referring to? thanks, Erich On Mon, Jul 25, 2011 at 12:24 PM, Harman, Daniel A <dan...@jp...<mailto:dan...@jp...>> wrote: Hi all, Is this project still alive? I have read on stack overflow that it has issues with nlog2, which if the case is bad news as common.logging is fairly heavily embedded in a lot of open source projects. The only signs of life I've seen are the January nuget packages, but the build scripts for this aren't in the sourceforge repo. Kind Regards, Dan This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. ------------------------------------------------------------------------------ Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ _______________________________________________ Netcommon-developer mailing list Net...@li...<mailto:Net...@li...> https://lists.sourceforge.net/lists/listinfo/netcommon-developer ------------------------------------------------------------------------------ Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ _______________________________________________ Netcommon-developer mailing list Net...@li...<mailto:Net...@li...> https://lists.sourceforge.net/lists/listinfo/netcommon-developer |
|
From: Kenneth Xu <ke...@ho...> - 2011-07-29 16:13:11
|
Hi Danial, I have provided an answer to the 2nd link. For sending logs to NLog, CommonLogging works well with NLog2. All you need to do is to add assembly redirect in your app.config or web.config. HTH, Kenneth On Mon, Jul 25, 2011 at 12:11 PM, Harman, Daniel A < dan...@jp...> wrote: > Hi Erich,**** > > ** ** > > The two posts in question are:**** > > ** ** > > > http://stackoverflow.com/questions/6778233/are-there-any-alternatives-to-common-logging > **** > > ** ** > > and**** > > ** ** > > > http://stackoverflow.com/questions/6027997/can-nlog-v2-be-used-with-common-logging > **** > > ** ** > > (which mentions a problem using nlog2).**** > > ** ** > > This is the eternal curse of open source, everyone wants the products, but > finding time to contribute is not easy! I will take a look if some time > frees up, but I don't realistically think I can contribute at the moment.* > *** > > ** ** > > Is there a new code repository? When I browsed the source forge one, I > couldn't spot the nuget packaging scripts one normally sees with nuget > packages, which made me wonder if it had been forked. **** > > ** ** > > Kind regards**** > > ** ** > > *Daniel A Harman* | VP | Delta1/PT RAD | *J.P. Morgan* | 10 Aldermanbury, > London, EC2V 7RF | T: +44 (0) 207 742 6565 | F: +44 (0)207 325 3722 | * > dan...@jp...* | *jpmorgan.com***** > > ** ** > > *From:* Erich Eichinger [mailto:eei...@gm...] > *Sent:* 25 July 2011 15:04 > *To:* Harman, Daniel A > *Cc:* net...@li... > *Subject:* Re: [Netcommon-developer] Status of Common.Logging**** > > ** ** > > Dan, > > yes, this project is still alive. Admittedly it could need the help of some > contributors though! > > What StackOverflow post are you referring to? > > thanks, > Erich**** > > On Mon, Jul 25, 2011 at 12:24 PM, Harman, Daniel A < > dan...@jp...> wrote:**** > > Hi all,**** > > **** > > Is this project still alive? I have read on stack overflow that it has > issues with nlog2, which if the case is bad news as common.logging is fairly > heavily embedded in a lot of open source projects.**** > > **** > > The only signs of life I've seen are the January nuget packages, but the > build scripts for this aren't in the sourceforge repo.**** > > **** > > Kind Regards,**** > > **** > > Dan**** > > **** > > This email is confidential and subject to important disclaimers and > conditions including on offers for the purchase or sale of securities, > accuracy and completeness of information, viruses, confidentiality, legal > privilege, and legal entity disclaimers, available at > http://www.jpmorgan.com/pages/disclosures/email. **** > > > > ------------------------------------------------------------------------------ > Storage Efficiency Calculator > This modeling tool is based on patent-pending intellectual property that > has been used successfully in hundreds of IBM storage optimization engage- > ments, worldwide. Store less, Store more with what you own, Move data to > the right place. Try It Now! > http://www.accelacomm.com/jaw/sfnl/114/51427378/ > _______________________________________________ > Netcommon-developer mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netcommon-developer**** > > ** ** > > > ------------------------------------------------------------------------------ > Storage Efficiency Calculator > This modeling tool is based on patent-pending intellectual property that > has been used successfully in hundreds of IBM storage optimization engage- > ments, worldwide. Store less, Store more with what you own, Move data to > the right place. Try It Now! > http://www.accelacomm.com/jaw/sfnl/114/51427378/ > _______________________________________________ > Netcommon-developer mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netcommon-developer > > |
|
From: Harman, D. A <dan...@jp...> - 2011-07-25 16:11:37
|
Hi Erich, The two posts in question are: http://stackoverflow.com/questions/6778233/are-there-any-alternatives-to-common-logging and http://stackoverflow.com/questions/6027997/can-nlog-v2-be-used-with-common-logging (which mentions a problem using nlog2). This is the eternal curse of open source, everyone wants the products, but finding time to contribute is not easy! I will take a look if some time frees up, but I don't realistically think I can contribute at the moment. Is there a new code repository? When I browsed the source forge one, I couldn't spot the nuget packaging scripts one normally sees with nuget packages, which made me wonder if it had been forked. Kind regards Daniel A Harman | VP | Delta1/PT RAD | J.P. Morgan | 10 Aldermanbury, London, EC2V 7RF | T: +44 (0) 207 742 6565 | F: +44 (0)207 325 3722 | dan...@jp... | jpmorgan.com From: Erich Eichinger [mailto:eei...@gm...] Sent: 25 July 2011 15:04 To: Harman, Daniel A Cc: net...@li... Subject: Re: [Netcommon-developer] Status of Common.Logging Dan, yes, this project is still alive. Admittedly it could need the help of some contributors though! What StackOverflow post are you referring to? thanks, Erich On Mon, Jul 25, 2011 at 12:24 PM, Harman, Daniel A <dan...@jp...<mailto:dan...@jp...>> wrote: Hi all, Is this project still alive? I have read on stack overflow that it has issues with nlog2, which if the case is bad news as common.logging is fairly heavily embedded in a lot of open source projects. The only signs of life I've seen are the January nuget packages, but the build scripts for this aren't in the sourceforge repo. Kind Regards, Dan This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. ------------------------------------------------------------------------------ Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ _______________________________________________ Netcommon-developer mailing list Net...@li...<mailto:Net...@li...> https://lists.sourceforge.net/lists/listinfo/netcommon-developer |
|
From: Erich E. <eei...@gm...> - 2011-07-25 14:04:30
|
Dan, yes, this project is still alive. Admittedly it could need the help of some contributors though! What StackOverflow post are you referring to? thanks, Erich On Mon, Jul 25, 2011 at 12:24 PM, Harman, Daniel A < dan...@jp...> wrote: > Hi all,**** > > ** ** > > Is this project still alive? I have read on stack overflow that it has > issues with nlog2, which if the case is bad news as common.logging is fairly > heavily embedded in a lot of open source projects.**** > > ** ** > > The only signs of life I've seen are the January nuget packages, but the > build scripts for this aren't in the sourceforge repo.**** > > ** ** > > Kind Regards,**** > > ** ** > > Dan**** > > ** ** > > This email is confidential and subject to important disclaimers and > conditions including on offers for the purchase or sale of securities, > accuracy and completeness of information, viruses, confidentiality, legal > privilege, and legal entity disclaimers, available at > http://www.jpmorgan.com/pages/disclosures/email. > > > ------------------------------------------------------------------------------ > Storage Efficiency Calculator > This modeling tool is based on patent-pending intellectual property that > has been used successfully in hundreds of IBM storage optimization engage- > ments, worldwide. Store less, Store more with what you own, Move data to > the right place. Try It Now! > http://www.accelacomm.com/jaw/sfnl/114/51427378/ > _______________________________________________ > Netcommon-developer mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netcommon-developer > > |
|
From: Harman, D. A <dan...@jp...> - 2011-07-25 11:24:24
|
Hi all, Is this project still alive? I have read on stack overflow that it has issues with nlog2, which if the case is bad news as common.logging is fairly heavily embedded in a lot of open source projects. The only signs of life I've seen are the January nuget packages, but the build scripts for this aren't in the sourceforge repo. Kind Regards, Dan This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. |
|
From: Bruno B. <br...@gm...> - 2011-04-06 08:52:00
|
Hi, You will have to do that with the logging framework you choosed. - Bruno 2011/3/21 Dan Smeltz <dan...@gm...> > Is there an interface, via Common.Logging, that will let you specify > the Source, EventId and TaskCategory for a logged event? I realize > that this is specific to writing to a Windows Event Log, but it would > be nice to specify these items. > > Thanks, > Dan > > > ------------------------------------------------------------------------------ > Create and publish websites with WebMatrix > Use the most popular FREE web apps or write code yourself; > WebMatrix provides all the features you need to develop and > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf > _______________________________________________ > Netcommon-developer mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netcommon-developer > |
|
From: Bruno B. <br...@gm...> - 2011-03-30 09:00:49
|
Answer on StackOverflow : http://stackoverflow.com/questions/5366592/how-to-configure-microsoft-enterprise-library-logging-application-block-to-handle <http://stackoverflow.com/questions/5366592/how-to-configure-microsoft-enterprise-library-logging-application-block-to-handle> Subject closed. - Bruno 2011/3/20 Daniel Pincas <dan...@gm...> > Hello! > > First, I love this library. I was in the process of making a simple wrapper > interface for our own loggers when I came across this. Thank you! > > Second, I'm having a small problem getting it up and running. I'm using it, > with EntLib 41. Logging, in a simple ASP.NET MVC application, and whenever > I call it like so: > > public ActionResult Index() > { > > ViewBag.Message = "Welcome to ASP.NET MVC!"; > > ILog log = LogManager.GetCurrentClassLogger(); > > log.Info("Hello world!"); > > return View(); > } > > Instead of logging, it gets caught in an EntLib error because the category > seems to be generated automatically: > > Message: There is no explicit mapping for the categories > 'TestApp.Controllers.HomeController'. > > I've tried tweaking EntLib to accept any category, but there doesn't seem > to be a way to do that. Is there some way of telling the Logger to use the > "General" category? Or is this a bug? > > I'd appreciate any and all help with this problem. Additionally, I've > posted this question on StackOverflow ( > http://stackoverflow.com/questions/5366592/how-to-configure-microsoft-enterprise-library-logging-application-block-to-handle) -- > if you want, you could post your answer there and grab some easy points ;-) > > Thank you so much! > > Cheers, > > Dan Pincas > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Netcommon-developer mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netcommon-developer > > |
|
From: Dan S. <dan...@gm...> - 2011-03-21 17:00:54
|
Is there an interface, via Common.Logging, that will let you specify the Source, EventId and TaskCategory for a logged event? I realize that this is specific to writing to a Windows Event Log, but it would be nice to specify these items. Thanks, Dan |
|
From: Daniel P. <dan...@gm...> - 2011-03-20 15:42:26
|
Hello! First, I love this library. I was in the process of making a simple wrapper interface for our own loggers when I came across this. Thank you! Second, I'm having a small problem getting it up and running. I'm using it, with EntLib 41. Logging, in a simple ASP.NET MVC application, and whenever I call it like so: public ActionResult Index() { ViewBag.Message = "Welcome to ASP.NET MVC!"; ILog log = LogManager.GetCurrentClassLogger(); log.Info("Hello world!"); return View(); } Instead of logging, it gets caught in an EntLib error because the category seems to be generated automatically: Message: There is no explicit mapping for the categories 'TestApp.Controllers.HomeController'. I've tried tweaking EntLib to accept any category, but there doesn't seem to be a way to do that. Is there some way of telling the Logger to use the "General" category? Or is this a bug? I'd appreciate any and all help with this problem. Additionally, I've posted this question on StackOverflow ( http://stackoverflow.com/questions/5366592/how-to-configure-microsoft-enterprise-library-logging-application-block-to-handle) -- if you want, you could post your answer there and grab some easy points ;-) Thank you so much! Cheers, Dan Pincas |
|
From: Kenneth Xu <ke...@ho...> - 2010-10-27 03:39:05
|
I like the idea of having a property context in logmanager, it is cleaner to use as well as implement. |
|
From: Geoghegan, W. A (Willie) <wil...@in...> - 2010-10-25 20:24:01
|
One further thought on Logging Context.
Having thought about this since my last mail, I wonder if an approach
like this would be a good idea. Expose a property on the LogManager
that encapsulates all of the context properties and "stacks":
//
//IContextProperties, IContextStacks, and IContextStack as before.
//
public interface ILoggingContext
{
IContextProperties GlobalProperties { get; }
IContextProperties ThreadProperties { get; }
IContextStacks ThreadStacks { get; }
IContextProperties LogicalThreadProperties { get; }
IContextStacks LogicalThreadStacks { get; }
}
//
//ILoggerFactoryAdapter adds new property...
//
public interface ILoggerFactoryAdapter
{
//Leaving out existing methods/properties
ILoggingContext Context { get; set; }
}
//
//LogManager adds a new static property...
//
public static class LogManager
{
private static ILoggingContext _nullContext = new
NullLoggingContext();
//Leaving out existing methods/properties
//...
ILoggingContext Context
{
return (_adapter.Context == null) ? _nullContext : _adapter.Context;
}
}
Now you can write logging code like this:
LogManager.Context.GlobalProperties["id"] = GetGlobalIdFromSomewhere();
LogManager.Context.ThreadProperties["threadid"] =
GetThreadIdFromThread();
using (LogManager.Context.ThreadStacks["ndc"].Push("operation1"))
{
//All messages logged in this scope will be tagged with "operation1".
}
By adding Context as a property to LogManager, and having it be an
actual object instance, we can write extension methods against it. So,
if someone wanted to they could simplify the interface to the logging
context by making a "default" thread stack, like this:
public static class LoggingContextExtensions
{
//Consider the NDC as the default thread stack ...
public static IContextStack ThreadStack(this ILoggingContext context)
{
return context.ThreadStacks["ndc"];
}
}
Now logging code that uses "stacks" can be simplified like this:
using (LogManager.Context.ThreadStack().Push("operation1"))
{
}
Maybe a better extension name would be DefaultThreadStack or even NDC.
using (LogManager.Context.DefaultThreadStack().Push("operation1"))
{
}
using (LogManager.Context.NDC.Push("operation1"))
{
}
They could also simplify setting of properties (perhaps to encourage or
enforce coding/development/organizational standards) like this:
public static class LoggingContextExtensions
{
public static void SetAppStartTime(this ILoggingContext context,
DateTime start)
{
context.GlobalProperties["appstarttime"] = start;
}
}
LogManager.Context.SetAppStartTime(DateTime.Now);
This does not directly address the fact that log4net has a "logical
thread" context and NLog doesn't. The default implementation for NLog
could be to use "NullContext" objects for the "logical thread" context
properties when NLog is configured (decision of what to expose is
probably actually inside of the NLog adapter). Alternatively, if a
development organization is ambitious and really wants a "logical
context" they could implement one (following the way that log4net has
implemented theirs), expose it via the IContext.Logical* properties, and
access it via a custom NLog LayoutRenderer. All pretty straightforward
implementations.
Another benefit (or would it be "benefit" with air quotes) of exposing
the logging context as a property on LogManager (rather than as discrete
properties as I mentioned in my earlier email) is that someone could
write an extension method on IContext to expose a brand new type of
context. Say that you want to write an IContextProperties
implementation that uses HttpContext.Items. You could expose it
something like this (probably not a good implementation, used for
illustrative purposes only):
public MyHttpContextItemsWrapper : IContextProperties
{
object this [string key]
{
get
{
return HttpContext.Current.Items[key]
}
set
{
HttpContext.Current.Items[key] = value;
}
}
}
public static class LoggingContextExtensions
{
public static IContextProperties HttpContextItems(this ILoggingContext
context)
{
return new MyHttpContextItemsWrapper();
}
}
LogManager. Context.HttpContextItems["my http property"] = "hello";
The value of this completely new context can be output to the logging
stream by (at least in the case of log4net and NLog) by implementing a
custom "output operator" (like a log4net PatternLayoutConverter or a
NLog LayoutRenderer).
Thanks.
Willie Geoghegan.
|
|
From: Geoghegan, W. A (Willie) <wil...@in...> - 2010-10-20 20:37:35
|
That was a little bit more repetitious than I had intended (I should have reviewed my earlier message on this topic first). However, I think that it does go into quite a bit more detail than my earlier message plus I have had the intervening time to experiment with it. Anyway, thanks for taking the time to look at it. Willie Geoghegan. |
1 message has been excluded from this view by a project administrator.
