I was looking for you in Skype few minutes ago... I have to go now, I'll back in few hours and I will open another thread to let you know my thoughts about NH and external references.
On Wed, Aug 4, 2010 at 10:06 AM, Erich Eichinger <[email protected]>wrote: > Hi all, > > > > I am one of the authors of Common.Logging. If you are missing something in > Common.Logging, please let us know. I already had some discussions around > Common.Logging+NHibernate with Fabio and Oren long ago, I believe there were > some needs regarding logging context? > > > > As sourceforge is a big PITA, we recently decided to move over the project > to github, hopefully encouraging more people to contribute. Also we will > move the mailinglist and bugtracker, I will communicate the changes asap (by > the end of next week). > > > > As for introducing an external dependency, I fully understand your > concerns. 2 thoughts on this: > > > > 1) there seems to be a misconception: When using Common.Logging there is > only a dependency on Common.Logging, but *no* compile-time dependency on > log4net. Only if you configure Common.Logging to use log4net (by specifying > Common.Logging.Log4Net's LoggerFactoryAdapter in App.config) you obviously > have a *runtime* dependency on log4net. > > > > 2) As for avoiding any dependency on a logging framework at all, I'd love > to hear any ideas out there how to allow for using a logging framework > without introducing a compile-time dependency. My only idea would be to > hijack the existing System.Diagnostics.Trace API, providing TraceListeners > for plugging in the logging framework of your choice. > > As for migrating from log4net to System.Diagnostics, I attached a simple > POC demonstrating the idea for introducing a log4net-compatible logging > infrastructure. This should make the migration pretty much a no-brainer. > > I plan to conduct some performance-tests as well as tests regarding the > functional behavior - especially regarding maintaining the correct > stacktrace in the logs - after moving the project on github to see if this > idea makes sense. Any feedback is welcome! > > > > hth, > > Erich > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Fabio Maulo > *Sent:* 04 August 2010 11:37 > > *To:* [email protected] > *Subject:* Re: [nhibernate-development] Re: Logging Abstraction > > > > We need the Log before start anything else. > > The discussion about CommonLogging and custom log was part of that old > discussion. > > I'm inclined to say goodbye to any external reference (including Iesi... > even if not so "external") but, at this point, for logging we > will reinvent the wheel. > > If, using CommonLogging, we don't loose something important for NH then we > can use it. > > On Wed, Aug 4, 2010 at 12:37 AM, Patrick Earl <[email protected]> wrote: > > In order to use log4net with Common.Logging, the > Common.Logging.Log4Net assembly is required. Is it acceptable for > users to need to add a reference to Common.Logging.Log4Net to their > code? If this was unacceptable, the Common.Logging.Log4Net assembly > could be embedded in the NHibernate assembly directly. It seems that > the approach taken historically was to document the need for the extra > assembly reference and not embed anything. > > I understand there is also sometimes a need to hook into the logging > layer independent of the logging provider being used. I propose that > there be an NHibernate LogManager class that is used all over the > NHibernate code to get an ILog instance. Providing log interception > at that point would be a simple matter of creating a class that > implements ILog and delegates to the underlying Common.Logging manager > but also throws events when messages are logged. The event mechanism > would be the same one powering events such as IPostLoadEventListener. > I assume some of the comments by Ayende were referring to NHProf... > would this design cover any needs there without significant > difficulty? > > For the start-up configuration, after looking at the code, my best > interpretation of what Fabio said is that the log initialization code > should go at the start of BuildSessionFactory (before the call to the > proxy factory factory config). This would ensure that logging is > properly enabled during the initialization process. > > I've already started re-integrating the old Common.Logging patch into > the trunk. I will work towards the design proposed here in the mean > time. > > Patrick Earl > > > On Aug 2, 11:33 am, Fabio Maulo <[email protected]> wrote: > > Solution > > 1) add common logging > > 2) at NH startup look for log4net.dll (start-up mean just before > instantiate > > the bytecode-provider) > > 2a) where present autoconfigure common-logging/NH to work with log4net > > 3) for other logging framework we can just relay to common-logging > > configuration/restrictions. > > > > > -- > Fabio Maulo > -- Fabio Maulo
