Not, really, it can't. NH needs to have multiple destination, the ability to turn some parts on/off, to ensure that no exceptions are ever thrown from the logging, etc.
On Fri, Aug 6, 2010 at 11:19 AM, Julian <[email protected]> wrote: > 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 >
