There are two aspects to logging: 1) generating log messages, and 2) recording log messages to a file/database/MSMQ/etc. NHibernate only needs to generate log messages, and it can do this using System.Diagnostics. It is then up to the user how they handle those logs by implementing an appropriate .NET trace listener. I'm not suggesting System.Diagnostics is the best logging solution out there, but there are some benefits:
- It could be considered a neutral choice since it doesn't favor one logger over another. - Reduces so-called DLL shock - Puts the 'N' back into NHibernate :) - Third-party loggers/applications can implement a trace listener - log4net already provides one On Aug 5, 2:35 am, Fabio Maulo <[email protected]> wrote: > I remember the time when I have removed the reference to Castle from > NH-Core. > The advantage was clear for who, like me, was a Castle-trunk user: no more > egg and chicken problem (aka bergamotta circular) > > The wrong decision, at the time, was to force a new property > configuration... probably I'll remove this constraint in a way or another > without force a default. > > For what I saw in my work, at least 90% of application, using NHibernate, > are WEB applications. > At least 90% of those WEB application are using Castle.DynProxy2 as > dyn-proxy system. > > So far, for NH3 they will have to deploy: > NHibernate, Iesi.Collection, re-linq, Antlr3, NHibernate.Bytecode.Castle, > Castle.Core, Castle.DynProxy2 and log4net > 8 DLLs only because NHibernate > > To give support to Client-Profile we will have: > NHibernate, Iesi.Collection, re-linq, Antlr3, NHibernate.Bytecode.Castle, > Castle.Core, Castle.DynProxy2, log4net > and > NHibernate.Web, Common.Logging, Common.Logging.Log4Net > and > configuration of common logging in web.config > (note : they should download Common.Logging.Log4Net from another site). > > We will make happy at most 10% of users (supposing that all no-web > applications are interested in client-profile-support) and we will hurt 90%. > > Instead reduce NH's external-dependencies we will change one with another > and I can't see where is the benefit. > > Note: many NH's user are using NHProf, someone are using NHTrace (both based > in log4net), some other use directly log4net and probably mostly does > not activate the logger. > > Even if I think that we don't have to reinvent the wheel, I'm inclined to > use our solution removing the dependency to log4net but distributing a NH > version with a log4net adapter merged. > > That's my thought. > > -- > Fabio Maulo
