netcommon-developer — Discussion on the development of the netcommon libraries

Re: [Netcommon-developer] Common.Logging - EntLib

[Mark P. <Mar...@sp...>]

I mean download on some site other than sourceforge, likely www.springframework.net/downloads/netcommon
Mark


> -----Original Message-----
> From: Erich Eichinger [mailto:eei...@gm...]
> Sent: Thursday, January 15, 2009 11:09 AM
> To: 'Peter A. Kirk'; net...@li...
> Subject: Re: [Netcommon-developer] Common.Logging - EntLib
> 
> hmm. Just saw, that some unit tests implement ILog to capture output...
> I'll
> check this out to make migration easier and ping back here
> 
> Redirection unfort. won't work as I just notice, because you are using
> a
> different key...
> 
> stay tuned,
> Erich
> 
> -----Original Message-----
> From: Peter A. Kirk [mailto:pk...@al...]
> Sent: Donnerstag, 15. Jänner 2009 14:43
> To: net...@li...
> Subject: Re: [Netcommon-developer] Common.Logging - EntLib
> 
> Hi again.
> 
> Just FYI, it is not such a simple matter to rebuild Spring against the
> Common.Logging.dll rebuilt from the latest Common.Logging code
> checkout.
> 
> This is due to the fact that Spring provides an implementation of
> Common.Logging.ILog, and this interface has some extra methods (eg.
> TraceFormat, InfoFormat) in the latest code which were not included in
> 1.2.0.0 code which Spring implements. (So one would also need to add
> extra
> methods to Spring's code...)
> 
> So I'll try the binding-redirect.
> 
> Thanks,
> Peter
> 
> 
> > -----Original Message-----
> > From: Erich Eichinger [mailto:Eri...@sp...]
> > Sent: 14. januar 2009 22:58
> > To: Peter A. Kirk; net...@li...
> > Subject: RE: Common.Logging - EntLib
> >
> > Hi,
> >
> > you can safely use assembly version redirection
> > (http://msdn.microsoft.com/en-us/library/7wd6ex19.aspx) to
> > force Spring.NET to use the new version - the next version of
> > Common.Logging (version number is TBD) is guaranteed to be
> > binary compatible with 1.2.
> >
> > Another option is to simply rebuild the Spring.NET sources
> > against the new assembly.
> >
> > hth,
> > Erich
> >
> > -----Original Message-----
> > From: Peter A. Kirk [mailto:pk...@al...]
> > Sent: Mittwoch, 14. Jänner 2009 22:56
> > To: Erich Eichinger; net...@li...
> > Subject: RE: Common.Logging - EntLib
> >
> > Thanks - I have tried to rebuild the sources, and have
> > successfully generated the new Entlib41 assembly. So I can
> > get this to work fine in my application - except in an
> > application which uses Spring.net, because it is apparently
> > built against common.logging version 1.2.0, which means it
> > fails against the new dll I have built...
> >
> >
> >
> > > -----Original Message-----
> > > From: Erich Eichinger [mailto:Eri...@sp...]
> > > Sent: 14. januar 2009 12:44
> > > To: Peter A. Kirk; net...@li...
> > > Subject: RE: Common.Logging - EntLib
> > >
> > > Hi Peter,
> > >
> > > If you're not afraid of compiling the sources yourself, you
> > > find already everything in the trunk. Just check out the
> > > resolved issues to see, what has happened since 1.2.
> > > Not sure when we're going to make the next official release,
> > > because there are some unsolved discussions about the
> > > extended design of the ILog interface. If you want to take a
> > > look into it, I'd be happy to receive your (and everybody
> > > else's) feedback!
> > >
> > > cheers,
> > > Erich
> > >
> > > -----Original Message-----
> > > From: Peter A. Kirk [mailto:pk...@al...]
> > > Sent: Mittwoch, 14. Jänner 2009 11:34
> > > To: net...@li...
> > > Subject: [Netcommon-developer] Common.Logging - EntLib
> > >
> > > Hi
> > >
> > > I was really happy to discover "common logging", as our customers
> > > normally use either Log4Net or Enterprise Library Logging -
> > > so it would
> > > be great to simply be able to select this via configuration.
> > >
> > > I was wondering though if "common logging" will be updated to
> > > use EntLib
> > > 4.1? The current release is for 3.1.
> > >
> > > Thanks,
> > > Peter
> > >
> > > --------------------------------------------------------------
> > > ----------------
> > > 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
> > >
> >
> 
> -----------------------------------------------------------------------
> -----
> --
> 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
> 
> 
> -----------------------------------------------------------------------
> -------
> 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

Re: [Netcommon-developer] Common.Logging - EntLib

[Mark P. <Mar...@sp...>]

Erich,

Can you make a local build and we'll post it up for download in the interim.

Buyer beware clauses apply....

Mark 

> -----Original Message-----
> From: Erich Eichinger [mailto:eei...@gm...]
> Sent: Thursday, January 15, 2009 11:09 AM
> To: 'Peter A. Kirk'; net...@li...
> Subject: Re: [Netcommon-developer] Common.Logging - EntLib
> 
> hmm. Just saw, that some unit tests implement ILog to capture output...
> I'll
> check this out to make migration easier and ping back here
> 
> Redirection unfort. won't work as I just notice, because you are using
> a
> different key...
> 
> stay tuned,
> Erich
> 
> -----Original Message-----
> From: Peter A. Kirk [mailto:pk...@al...]
> Sent: Donnerstag, 15. Jänner 2009 14:43
> To: net...@li...
> Subject: Re: [Netcommon-developer] Common.Logging - EntLib
> 
> Hi again.
> 
> Just FYI, it is not such a simple matter to rebuild Spring against the
> Common.Logging.dll rebuilt from the latest Common.Logging code
> checkout.
> 
> This is due to the fact that Spring provides an implementation of
> Common.Logging.ILog, and this interface has some extra methods (eg.
> TraceFormat, InfoFormat) in the latest code which were not included in
> 1.2.0.0 code which Spring implements. (So one would also need to add
> extra
> methods to Spring's code...)
> 
> So I'll try the binding-redirect.
> 
> Thanks,
> Peter
> 
> 
> > -----Original Message-----
> > From: Erich Eichinger [mailto:Eri...@sp...]
> > Sent: 14. januar 2009 22:58
> > To: Peter A. Kirk; net...@li...
> > Subject: RE: Common.Logging - EntLib
> >
> > Hi,
> >
> > you can safely use assembly version redirection
> > (http://msdn.microsoft.com/en-us/library/7wd6ex19.aspx) to
> > force Spring.NET to use the new version - the next version of
> > Common.Logging (version number is TBD) is guaranteed to be
> > binary compatible with 1.2.
> >
> > Another option is to simply rebuild the Spring.NET sources
> > against the new assembly.
> >
> > hth,
> > Erich
> >
> > -----Original Message-----
> > From: Peter A. Kirk [mailto:pk...@al...]
> > Sent: Mittwoch, 14. Jänner 2009 22:56
> > To: Erich Eichinger; net...@li...
> > Subject: RE: Common.Logging - EntLib
> >
> > Thanks - I have tried to rebuild the sources, and have
> > successfully generated the new Entlib41 assembly. So I can
> > get this to work fine in my application - except in an
> > application which uses Spring.net, because it is apparently
> > built against common.logging version 1.2.0, which means it
> > fails against the new dll I have built...
> >
> >
> >
> > > -----Original Message-----
> > > From: Erich Eichinger [mailto:Eri...@sp...]
> > > Sent: 14. januar 2009 12:44
> > > To: Peter A. Kirk; net...@li...
> > > Subject: RE: Common.Logging - EntLib
> > >
> > > Hi Peter,
> > >
> > > If you're not afraid of compiling the sources yourself, you
> > > find already everything in the trunk. Just check out the
> > > resolved issues to see, what has happened since 1.2.
> > > Not sure when we're going to make the next official release,
> > > because there are some unsolved discussions about the
> > > extended design of the ILog interface. If you want to take a
> > > look into it, I'd be happy to receive your (and everybody
> > > else's) feedback!
> > >
> > > cheers,
> > > Erich
> > >
> > > -----Original Message-----
> > > From: Peter A. Kirk [mailto:pk...@al...]
> > > Sent: Mittwoch, 14. Jänner 2009 11:34
> > > To: net...@li...
> > > Subject: [Netcommon-developer] Common.Logging - EntLib
> > >
> > > Hi
> > >
> > > I was really happy to discover "common logging", as our customers
> > > normally use either Log4Net or Enterprise Library Logging -
> > > so it would
> > > be great to simply be able to select this via configuration.
> > >
> > > I was wondering though if "common logging" will be updated to
> > > use EntLib
> > > 4.1? The current release is for 3.1.
> > >
> > > Thanks,
> > > Peter
> > >
> > > --------------------------------------------------------------
> > > ----------------
> > > 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
> > >
> >
> 
> -----------------------------------------------------------------------
> -----
> --
> 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
> 
> 
> -----------------------------------------------------------------------
> -------
> 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

Re: [Netcommon-developer] Common.Logging - EntLib

[Mark P. <Mar...@sp...>]

Hi,
Ok, let me take one last look at the new methods to close this loop and we will make a release next week...
Mark


> -----Original Message-----
> From: Erich Eichinger [mailto:eei...@gm...]
> Sent: Thursday, January 15, 2009 11:09 AM
> To: 'Peter A. Kirk'; net...@li...
> Subject: Re: [Netcommon-developer] Common.Logging - EntLib
> 
> hmm. Just saw, that some unit tests implement ILog to capture output...
> I'll
> check this out to make migration easier and ping back here
> 
> Redirection unfort. won't work as I just notice, because you are using
> a
> different key...
> 
> stay tuned,
> Erich
> 
> -----Original Message-----
> From: Peter A. Kirk [mailto:pk...@al...]
> Sent: Donnerstag, 15. Jänner 2009 14:43
> To: net...@li...
> Subject: Re: [Netcommon-developer] Common.Logging - EntLib
> 
> Hi again.
> 
> Just FYI, it is not such a simple matter to rebuild Spring against the
> Common.Logging.dll rebuilt from the latest Common.Logging code
> checkout.
> 
> This is due to the fact that Spring provides an implementation of
> Common.Logging.ILog, and this interface has some extra methods (eg.
> TraceFormat, InfoFormat) in the latest code which were not included in
> 1.2.0.0 code which Spring implements. (So one would also need to add
> extra
> methods to Spring's code...)
> 
> So I'll try the binding-redirect.
> 
> Thanks,
> Peter
> 
> 
> > -----Original Message-----
> > From: Erich Eichinger [mailto:Eri...@sp...]
> > Sent: 14. januar 2009 22:58
> > To: Peter A. Kirk; net...@li...
> > Subject: RE: Common.Logging - EntLib
> >
> > Hi,
> >
> > you can safely use assembly version redirection
> > (http://msdn.microsoft.com/en-us/library/7wd6ex19.aspx) to
> > force Spring.NET to use the new version - the next version of
> > Common.Logging (version number is TBD) is guaranteed to be
> > binary compatible with 1.2.
> >
> > Another option is to simply rebuild the Spring.NET sources
> > against the new assembly.
> >
> > hth,
> > Erich
> >
> > -----Original Message-----
> > From: Peter A. Kirk [mailto:pk...@al...]
> > Sent: Mittwoch, 14. Jänner 2009 22:56
> > To: Erich Eichinger; net...@li...
> > Subject: RE: Common.Logging - EntLib
> >
> > Thanks - I have tried to rebuild the sources, and have
> > successfully generated the new Entlib41 assembly. So I can
> > get this to work fine in my application - except in an
> > application which uses Spring.net, because it is apparently
> > built against common.logging version 1.2.0, which means it
> > fails against the new dll I have built...
> >
> >
> >
> > > -----Original Message-----
> > > From: Erich Eichinger [mailto:Eri...@sp...]
> > > Sent: 14. januar 2009 12:44
> > > To: Peter A. Kirk; net...@li...
> > > Subject: RE: Common.Logging - EntLib
> > >
> > > Hi Peter,
> > >
> > > If you're not afraid of compiling the sources yourself, you
> > > find already everything in the trunk. Just check out the
> > > resolved issues to see, what has happened since 1.2.
> > > Not sure when we're going to make the next official release,
> > > because there are some unsolved discussions about the
> > > extended design of the ILog interface. If you want to take a
> > > look into it, I'd be happy to receive your (and everybody
> > > else's) feedback!
> > >
> > > cheers,
> > > Erich
> > >
> > > -----Original Message-----
> > > From: Peter A. Kirk [mailto:pk...@al...]
> > > Sent: Mittwoch, 14. Jänner 2009 11:34
> > > To: net...@li...
> > > Subject: [Netcommon-developer] Common.Logging - EntLib
> > >
> > > Hi
> > >
> > > I was really happy to discover "common logging", as our customers
> > > normally use either Log4Net or Enterprise Library Logging -
> > > so it would
> > > be great to simply be able to select this via configuration.
> > >
> > > I was wondering though if "common logging" will be updated to
> > > use EntLib
> > > 4.1? The current release is for 3.1.
> > >
> > > Thanks,
> > > Peter
> > >
> > > --------------------------------------------------------------
> > > ----------------
> > > 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
> > >
> >
> 
> -----------------------------------------------------------------------
> -----
> --
> 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
> 
> 
> -----------------------------------------------------------------------
> -------
> 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

Re: [Netcommon-developer] Common.Logging - EntLib

[Erich E. <eei...@gm...>]

hmm. Just saw, that some unit tests implement ILog to capture output... I'll
check this out to make migration easier and ping back here

Redirection unfort. won't work as I just notice, because you are using a
different key...

stay tuned,
Erich

-----Original Message-----
From: Peter A. Kirk [mailto:pk...@al...] 
Sent: Donnerstag, 15. Jänner 2009 14:43
To: net...@li...
Subject: Re: [Netcommon-developer] Common.Logging - EntLib

Hi again. 

Just FYI, it is not such a simple matter to rebuild Spring against the
Common.Logging.dll rebuilt from the latest Common.Logging code checkout. 

This is due to the fact that Spring provides an implementation of
Common.Logging.ILog, and this interface has some extra methods (eg.
TraceFormat, InfoFormat) in the latest code which were not included in
1.2.0.0 code which Spring implements. (So one would also need to add extra
methods to Spring's code...)

So I'll try the binding-redirect.

Thanks,
Peter


> -----Original Message-----
> From: Erich Eichinger [mailto:Eri...@sp...] 
> Sent: 14. januar 2009 22:58
> To: Peter A. Kirk; net...@li...
> Subject: RE: Common.Logging - EntLib
> 
> Hi,
> 
> you can safely use assembly version redirection 
> (http://msdn.microsoft.com/en-us/library/7wd6ex19.aspx) to 
> force Spring.NET to use the new version - the next version of 
> Common.Logging (version number is TBD) is guaranteed to be 
> binary compatible with 1.2. 
> 
> Another option is to simply rebuild the Spring.NET sources 
> against the new assembly. 
> 
> hth,
> Erich
> 
> -----Original Message-----
> From: Peter A. Kirk [mailto:pk...@al...] 
> Sent: Mittwoch, 14. Jänner 2009 22:56
> To: Erich Eichinger; net...@li...
> Subject: RE: Common.Logging - EntLib
> 
> Thanks - I have tried to rebuild the sources, and have 
> successfully generated the new Entlib41 assembly. So I can 
> get this to work fine in my application - except in an 
> application which uses Spring.net, because it is apparently 
> built against common.logging version 1.2.0, which means it 
> fails against the new dll I have built...
> 
> 
> 
> > -----Original Message-----
> > From: Erich Eichinger [mailto:Eri...@sp...] 
> > Sent: 14. januar 2009 12:44
> > To: Peter A. Kirk; net...@li...
> > Subject: RE: Common.Logging - EntLib
> > 
> > Hi Peter,
> > 
> > If you're not afraid of compiling the sources yourself, you 
> > find already everything in the trunk. Just check out the 
> > resolved issues to see, what has happened since 1.2. 
> > Not sure when we're going to make the next official release, 
> > because there are some unsolved discussions about the 
> > extended design of the ILog interface. If you want to take a 
> > look into it, I'd be happy to receive your (and everybody 
> > else's) feedback!
> > 
> > cheers,
> > Erich
> > 
> > -----Original Message-----
> > From: Peter A. Kirk [mailto:pk...@al...] 
> > Sent: Mittwoch, 14. Jänner 2009 11:34
> > To: net...@li...
> > Subject: [Netcommon-developer] Common.Logging - EntLib
> > 
> > Hi
> > 
> > I was really happy to discover "common logging", as our customers
> > normally use either Log4Net or Enterprise Library Logging - 
> > so it would
> > be great to simply be able to select this via configuration.
> > 
> > I was wondering though if "common logging" will be updated to 
> > use EntLib
> > 4.1? The current release is for 3.1.
> > 
> > Thanks,
> > Peter
> > 
> > --------------------------------------------------------------
> > ----------------
> > 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
> > 
> 

----------------------------------------------------------------------------
--
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

Re: [Netcommon-developer] Common.Logging - EntLib

[Peter A. K. <pk...@al...>]

Hi again. 

Just FYI, it is not such a simple matter to rebuild Spring against the Common.Logging.dll rebuilt from the latest Common.Logging code checkout. 

This is due to the fact that Spring provides an implementation of Common.Logging.ILog, and this interface has some extra methods (eg. TraceFormat, InfoFormat) in the latest code which were not included in 1.2.0.0 code which Spring implements. (So one would also need to add extra methods to Spring's code...)

So I'll try the binding-redirect.

Thanks,
Peter


> -----Original Message-----
> From: Erich Eichinger [mailto:Eri...@sp...] 
> Sent: 14. januar 2009 22:58
> To: Peter A. Kirk; net...@li...
> Subject: RE: Common.Logging - EntLib
> 
> Hi,
> 
> you can safely use assembly version redirection 
> (http://msdn.microsoft.com/en-us/library/7wd6ex19.aspx) to 
> force Spring.NET to use the new version - the next version of 
> Common.Logging (version number is TBD) is guaranteed to be 
> binary compatible with 1.2. 
> 
> Another option is to simply rebuild the Spring.NET sources 
> against the new assembly. 
> 
> hth,
> Erich
> 
> -----Original Message-----
> From: Peter A. Kirk [mailto:pk...@al...] 
> Sent: Mittwoch, 14. Jänner 2009 22:56
> To: Erich Eichinger; net...@li...
> Subject: RE: Common.Logging - EntLib
> 
> Thanks - I have tried to rebuild the sources, and have 
> successfully generated the new Entlib41 assembly. So I can 
> get this to work fine in my application - except in an 
> application which uses Spring.net, because it is apparently 
> built against common.logging version 1.2.0, which means it 
> fails against the new dll I have built...
> 
> 
> 
> > -----Original Message-----
> > From: Erich Eichinger [mailto:Eri...@sp...] 
> > Sent: 14. januar 2009 12:44
> > To: Peter A. Kirk; net...@li...
> > Subject: RE: Common.Logging - EntLib
> > 
> > Hi Peter,
> > 
> > If you're not afraid of compiling the sources yourself, you 
> > find already everything in the trunk. Just check out the 
> > resolved issues to see, what has happened since 1.2. 
> > Not sure when we're going to make the next official release, 
> > because there are some unsolved discussions about the 
> > extended design of the ILog interface. If you want to take a 
> > look into it, I'd be happy to receive your (and everybody 
> > else's) feedback!
> > 
> > cheers,
> > Erich
> > 
> > -----Original Message-----
> > From: Peter A. Kirk [mailto:pk...@al...] 
> > Sent: Mittwoch, 14. Jänner 2009 11:34
> > To: net...@li...
> > Subject: [Netcommon-developer] Common.Logging - EntLib
> > 
> > Hi
> > 
> > I was really happy to discover "common logging", as our customers
> > normally use either Log4Net or Enterprise Library Logging - 
> > so it would
> > be great to simply be able to select this via configuration.
> > 
> > I was wondering though if "common logging" will be updated to 
> > use EntLib
> > 4.1? The current release is for 3.1.
> > 
> > Thanks,
> > Peter
> > 
> > --------------------------------------------------------------
> > ----------------
> > 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
> > 
> 

Re: [Netcommon-developer] Common.Logging - EntLib

[Peter A. K. <pk...@al...>]

Thanks - I have tried to rebuild the sources, and have successfully generated the new Entlib41 assembly. So I can get this to work fine in my application - except in an application which uses Spring.net, because it is apparently built against common.logging version 1.2.0, which means it fails against the new dll I have built...



> -----Original Message-----
> From: Erich Eichinger [mailto:Eri...@sp...] 
> Sent: 14. januar 2009 12:44
> To: Peter A. Kirk; net...@li...
> Subject: RE: Common.Logging - EntLib
> 
> Hi Peter,
> 
> If you're not afraid of compiling the sources yourself, you 
> find already everything in the trunk. Just check out the 
> resolved issues to see, what has happened since 1.2. 
> Not sure when we're going to make the next official release, 
> because there are some unsolved discussions about the 
> extended design of the ILog interface. If you want to take a 
> look into it, I'd be happy to receive your (and everybody 
> else's) feedback!
> 
> cheers,
> Erich
> 
> -----Original Message-----
> From: Peter A. Kirk [mailto:pk...@al...] 
> Sent: Mittwoch, 14. Jänner 2009 11:34
> To: net...@li...
> Subject: [Netcommon-developer] Common.Logging - EntLib
> 
> Hi
> 
> I was really happy to discover "common logging", as our customers
> normally use either Log4Net or Enterprise Library Logging - 
> so it would
> be great to simply be able to select this via configuration.
> 
> I was wondering though if "common logging" will be updated to 
> use EntLib
> 4.1? The current release is for 3.1.
> 
> Thanks,
> Peter
> 
> --------------------------------------------------------------
> ----------------
> 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
> 

Re: [Netcommon-developer] Common.Logging - EntLib

[Erich E. <Eri...@sp...>]

Hi,

you can safely use assembly version redirection (http://msdn.microsoft.com/en-us/library/7wd6ex19.aspx) to force Spring.NET to use the new version - the next version of Common.Logging (version number is TBD) is guaranteed to be binary compatible with 1.2. 

Another option is to simply rebuild the Spring.NET sources against the new assembly. 

hth,
Erich

-----Original Message-----
From: Peter A. Kirk [mailto:pk...@al...] 
Sent: Mittwoch, 14. Jänner 2009 22:56
To: Erich Eichinger; net...@li...
Subject: RE: Common.Logging - EntLib

Thanks - I have tried to rebuild the sources, and have successfully generated the new Entlib41 assembly. So I can get this to work fine in my application - except in an application which uses Spring.net, because it is apparently built against common.logging version 1.2.0, which means it fails against the new dll I have built...



> -----Original Message-----
> From: Erich Eichinger [mailto:Eri...@sp...] 
> Sent: 14. januar 2009 12:44
> To: Peter A. Kirk; net...@li...
> Subject: RE: Common.Logging - EntLib
> 
> Hi Peter,
> 
> If you're not afraid of compiling the sources yourself, you 
> find already everything in the trunk. Just check out the 
> resolved issues to see, what has happened since 1.2. 
> Not sure when we're going to make the next official release, 
> because there are some unsolved discussions about the 
> extended design of the ILog interface. If you want to take a 
> look into it, I'd be happy to receive your (and everybody 
> else's) feedback!
> 
> cheers,
> Erich
> 
> -----Original Message-----
> From: Peter A. Kirk [mailto:pk...@al...] 
> Sent: Mittwoch, 14. Jänner 2009 11:34
> To: net...@li...
> Subject: [Netcommon-developer] Common.Logging - EntLib
> 
> Hi
> 
> I was really happy to discover "common logging", as our customers
> normally use either Log4Net or Enterprise Library Logging - 
> so it would
> be great to simply be able to select this via configuration.
> 
> I was wondering though if "common logging" will be updated to 
> use EntLib
> 4.1? The current release is for 3.1.
> 
> Thanks,
> Peter
> 
> --------------------------------------------------------------
> ----------------
> 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
> 

Re: [Netcommon-developer] Common.Logging - EntLib

[Mark P. <Mar...@sp...>]

Hi,

Erich Eichinger has done this already, the code is in svn and we were planning to make a 2.0 release but it has been held up because I want to review the changes to the API.  I'm almost convinced on the changes that Erich made...  In anycase, is it possible in the meantime for you to check the code out of svn and do a build?  You will need to generate your own private key to perform the build.

Cheers,
Mark

> -----Original Message-----
> From: Peter A. Kirk [mailto:pk...@al...]
> Sent: Wednesday, January 14, 2009 5:34 AM
> To: net...@li...
> Subject: [Netcommon-developer] Common.Logging - EntLib
> 
> Hi
> 
> I was really happy to discover "common logging", as our customers
> normally use either Log4Net or Enterprise Library Logging - so it would
> be great to simply be able to select this via configuration.
> 
> I was wondering though if "common logging" will be updated to use
> EntLib
> 4.1? The current release is for 3.1.
> 
> Thanks,
> Peter
> 
> -----------------------------------------------------------------------
> -------
> 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

Re: [Netcommon-developer] Common.Logging - EntLib

[Erich E. <Eri...@sp...>]

Hi Peter,

If you're not afraid of compiling the sources yourself, you find already everything in the trunk. Just check out the resolved issues to see, what has happened since 1.2. 
Not sure when we're going to make the next official release, because there are some unsolved discussions about the extended design of the ILog interface. If you want to take a look into it, I'd be happy to receive your (and everybody else's) feedback!

cheers,
Erich

-----Original Message-----
From: Peter A. Kirk [mailto:pk...@al...] 
Sent: Mittwoch, 14. Jänner 2009 11:34
To: net...@li...
Subject: [Netcommon-developer] Common.Logging - EntLib

Hi

I was really happy to discover "common logging", as our customers
normally use either Log4Net or Enterprise Library Logging - so it would
be great to simply be able to select this via configuration.

I was wondering though if "common logging" will be updated to use EntLib
4.1? The current release is for 3.1.

Thanks,
Peter

------------------------------------------------------------------------------
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

Re: [Netcommon-developer] Common.Logging - EntLib

[Erich E. <eei...@gm...>]

Hi Peter,

If you're not afraid of compiling the sources yourself, you find already
everything in the trunk. Just check out the resolved issues to see, what has
happened since 1.2. 
Not sure when we're going to make the next official release, because there
are some unsolved discussions about the extended design of the ILog
interface. If you want to take a look into it, I'd be happy to receive your
(and everybody else's) feedback!

cheers,
Erich

-----Original Message-----
From: Peter A. Kirk [mailto:pk...@al...] 
Sent: Mittwoch, 14. Jänner 2009 11:34
To: net...@li...
Subject: [Netcommon-developer] Common.Logging - EntLib

Hi

I was really happy to discover "common logging", as our customers
normally use either Log4Net or Enterprise Library Logging - so it would
be great to simply be able to select this via configuration.

I was wondering though if "common logging" will be updated to use EntLib
4.1? The current release is for 3.1.

Thanks,
Peter

----------------------------------------------------------------------------
--
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

[Netcommon-developer] Common.Logging - EntLib

[Peter A. K. <pk...@al...>]

Hi

I was really happy to discover "common logging", as our customers
normally use either Log4Net or Enterprise Library Logging - so it would
be great to simply be able to select this via configuration.

I was wondering though if "common logging" will be updated to use EntLib
4.1? The current release is for 3.1.

Thanks,
Peter

Re: [Netcommon-developer] Is development still active?

[Erich E. <eri...@sp...>]

Hi Brian,

I just resolved most of the open issues (we will officially close them at
a later time). I will add EntLib 4.1 support tomorrow. I'd be happy if you
(or anyone else interested out there) review and comment on the new
extended ILog interface and features. Let me know, if there is something
missing for integration w/ NHibernate or if we can be of any help!

Grab the sources via svn at
"https://netcommon.svn.sourceforge.net/svnroot/netcommon/projects/logging/
trunk". Building your own signed assemblies is done best by placing your
.snk key file into $\logging\modules and executing "nant build package".

cheers,
Erich

---------- Forwarded message ----------
From: Brian Chavez
Date: 2008/10/28
Subject: [Netcommon-developer] Is development still active?
To: net...@li...



Hi,

 

We are currently debating on using Common.Logging for use in NHibernate.

 

However, we would like to know if your project is still active and if
there is any effort in resolving the bugs & feature requests found here:

 

http://sourceforge.net/tracker/?atid=901156
<http://sourceforge.net/tracker/?atid=901156&group_id=182424&func=browse>
&group_id=182424&func=browse

 

http://sourceforge.net/tracker/?atid=901159
<http://sourceforge.net/tracker/?atid=901159&group_id=182424&func=browse>
&group_id=182424&func=browse

 

Many thanks,

Brian

 


----------------------------------------------
Brian Chavez
Bit Armory, Inc.
http://www.bitarmory.com

 


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100
<http://moblin-contest.org/redirect.php?banner_id=100&url=/> &url=/
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer

 

Re: [Netcommon-developer] Is development still active?

[Mark P. <mar...@sp...>]

Hi,

Yes it is still active, I founded the project and do most of the development, Bruno Baia is another developer on the project.  I'd be quite happy to use this opportunity to make a new release of Commons.Logging that addresses the remaining open issues.  Are there other feature requests that would be specific to NHibernate adopting Common.Logging?  As for the 'when', starting in the 2nd week of November I'll have time to address these issues, I don't think they will take long to fix.

Cheers,
Mark




----- Original Message -----
From: "Brian Chavez" <bc...@bi...>
To: net...@li...
Sent: Tuesday, October 28, 2008 4:57:07 PM GMT -05:00 US/Canada Eastern
Subject: [Netcommon-developer] Is development still active?





Hi, 



We are currently debating on using Common.Logging for use in NHibernate. 



However, we would like to know if your project is still active and if there is any effort in resolving the bugs & feature requests found here: 



http://sourceforge.net/tracker/?atid=901156&group_id=182424&func=browse 



http://sourceforge.net/tracker/?atid=901159&group_id=182424&func=browse 



Many thanks, 

Brian 




---------------------------------------------- 
Brian Chavez 
Bit Armory, Inc. 
http://www.bitarmory.com 


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer

Re: [Netcommon-developer] Is development still active?

[Mark P. <mar...@sp...>]

Hi,

Yes it is still active, I founded the project and do most of the development, Bruno Baia is another developer on the project.  I'd be quite happy to use this opportunity to make a new release of Commons.Logging that addresses the remaining open issues.  Are there other feature requests that would be specific to NHibernate adopting Common.Logging?  As for the 'when', starting in the 2nd week of November I'll have time to address these issues, I don't think they will take long to fix.

Cheers,
Mark




----- Original Message -----
From: "Brian Chavez" <bc...@bi...>
To: net...@li...
Sent: Tuesday, October 28, 2008 4:57:07 PM GMT -05:00 US/Canada Eastern
Subject: [Netcommon-developer] Is development still active?





Hi, 



We are currently debating on using Common.Logging for use in NHibernate. 



However, we would like to know if your project is still active and if there is any effort in resolving the bugs & feature requests found here: 



http://sourceforge.net/tracker/?atid=901156&group_id=182424&func=browse 



http://sourceforge.net/tracker/?atid=901159&group_id=182424&func=browse 



Many thanks, 

Brian 




---------------------------------------------- 
Brian Chavez 
Bit Armory, Inc. 
http://www.bitarmory.com 


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer

[Netcommon-developer] Is development still active?

[Brian C. <bc...@bi...>]

Hi,

 

We are currently debating on using Common.Logging for use in NHibernate.

 

However, we would like to know if your project is still active and if there
is any effort in resolving the bugs & feature requests found here:

 

http://sourceforge.net/tracker/?atid=901156
<http://sourceforge.net/tracker/?atid=901156&group_id=182424&func=browse>
&group_id=182424&func=browse

 

http://sourceforge.net/tracker/?atid=901159
<http://sourceforge.net/tracker/?atid=901159&group_id=182424&func=browse>
&group_id=182424&func=browse

 

Many thanks,

Brian

 


----------------------------------------------
Brian Chavez
Bit Armory, Inc.
 <http://www.bitarmory.com> http://www.bitarmory.com

 

[Netcommon-developer] Common.Logging 1.2.0 released

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

Hi everyone,

 

Common.Logging 1.2.0 is out.  You can pick it up here:
http://sourceforge.net/project/showfiles.php?group_id=182424

 

Release notes are

 

Summary: New Features and Bug Fix release

 

Feature Requests

 

[1749340] - Add support for EntLib logging 

[1807769] - Add Trace level method to ILog interface  

 

Bug

 

[1792900] - NLog logging is not performed relative to correct callsite

 

 

Enjoy!

 

Mark

 

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

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

I made the changes but got bogged down in testing...I'll try for tomorrow.
Cheers,
Mark
 

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

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


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

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


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

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

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

Thanks.

<adrian />



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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer

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

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

Hi,

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

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

Regards,
Mark






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

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

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

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

With NLog, I can do this

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

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

If I use netcommon, I have to:

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

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

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

<adrian />


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

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


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

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


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

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

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

Thanks.

<adrian />



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


------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer

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

[Adrian R. <aro...@ef...>]

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

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

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

With NLog, I can do this

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

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

If I use netcommon, I have to:

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

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

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

<adrian />


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

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


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

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


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

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

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

Thanks.

<adrian />



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


------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer

[Netcommon-developer] adding Trace method to ILog

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

Hi,

 

This seems like an oversight, the 'Trace' level is not on the ILog interface
but most logging implementations have such a level.  I'll schedule this for
a 1.2 release unless there are objectsion.

 

Cheers,

Mark

 

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

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

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


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

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


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

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

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

Thanks.

<adrian />



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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer

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

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

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


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

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

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

Thanks.

<adrian />



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

[Netcommon-developer] Common.Logging/callsite question

[Adrian R. <aro...@ef...>]

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

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

Thanks.

<adrian />

Re: [Netcommon-developer] dll in gac

[Wang, G. <gw...@ae...>]

=20

Thanks Bruno.  That's the problem.  (It took me a while to figure it out
thought:-))

From: Bruno Baia [mailto:br...@gm...]=20
Sent: Friday, May 18, 2007 5:15 PM
To: Mark Pollack
Cc: Wang, George; net...@li...
Subject: Re: [Netcommon-developer] dll in gac

=20

Hi George,

=20

If you registered dll into the GAC, don't forget to use full assembly
qualified name :

=20

exemple for the log4net 1.2.10 factory adapter :

=20

Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter,
Common.Logging.Log4Net, Version=3D1.0.2.2, Culture=3Dneutral,
PublicKeyToken=3Daf08829b84f0328e
=20

=20

HTH,=20

Bruno
=20

2007/5/18, Mark Pollack <mpo...@in...>:=20

Hi George,

By not work I guess you mean you don't see any logging?  The behavior in
the
current release is to silently fail to using the NoOpLogger (which
doesn't=20
do any logging) if the specified factory adapter can't be found.  I've
changed that behavior in the code that is in CVS, so an
ConfigurationException is thrown.

But onto your issue.  Are you using the log4net factory adapter?  If you
are=20
make sure that for log4net 1.2.10 you use the type

1.2.10 -> Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter,
Common.Logging.Log4net

And for 1.2.9

1.2.9  -> Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter ,
Common.Logging.Log4Net129


And that they are also in the GAC or in the bin path.

If you could try with the 'built-in' factory adapters, i.e
Common.Logging.Simple.ConsoleOutLoggerFactoryAdapter , Common.Logging

Hope this helps.

Cheers,
Mark





-----Original Message-----
From: net...@li...=20
[mailto:net...@li...] On Behalf Of
Wang, George
Sent: Friday, May 18, 2007 4:04 PM
To: net...@li...
Subject: [Netcommon-developer] dll in gac

Hi,

It works when I put the dlls in the bin directory.  But it stopped
working when all the dlls are moved to the GAC.  Any idea why?=20

Best Regards,
George



------------------------------------------------------------------------
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take=20
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Netcommon-developer mailing list=20
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer=20




------------------------------------------------------------------------
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.=20
http://sourceforge.net/powerbar/db2/
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer

=20

Re: [Netcommon-developer] dll in gac

[Bruno B. <br...@gm...>]

Hi George,

If you registered dll into the GAC, don't forget to use full assembly
qualified name :

exemple for the log4net 1.2.10 factory adapter :

Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter, Common.Logging.Log4Net,
Version=1.0.2.2, Culture=neutral, PublicKeyToken=af08829b84f0328e


HTH,
Bruno

2007/5/18, Mark Pollack <mpo...@in...>:
>
> Hi George,
>
> By not work I guess you mean you don't see any logging?  The behavior in
> the
> current release is to silently fail to using the NoOpLogger (which doesn't
> do any logging) if the specified factory adapter can't be found.  I've
> changed that behavior in the code that is in CVS, so an
> ConfigurationException is thrown.
>
> But onto your issue.  Are you using the log4net factory adapter?  If you
> are
> make sure that for log4net 1.2.10 you use the type
>
> 1.2.10 -> Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter,
> Common.Logging.Log4net
>
> And for 1.2.9
>
> 1.2.9  -> Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter,
> Common.Logging.Log4Net129
>
>
> And that they are also in the GAC or in the bin path.
>
> If you could try with the 'built-in' factory adapters, i.e
> Common.Logging.Simple.ConsoleOutLoggerFactoryAdapter, Common.Logging
>
> Hope this helps.
>
> Cheers,
> Mark
>
>
>
>
>
> -----Original Message-----
> From: net...@li...
> [mailto:net...@li...] On Behalf Of
> Wang, George
> Sent: Friday, May 18, 2007 4:04 PM
> To: net...@li...
> Subject: [Netcommon-developer] dll in gac
>
> Hi,
>
> It works when I put the dlls in the bin directory.  But it stopped
> working when all the dlls are moved to the GAC.  Any idea why?
>
> Best Regards,
> George
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>