I don't really understand what you mean, but I'm sure you are correct. In any case I was talking theoretically as I'm not familiar with NH logging. Theoretically I felt that System.Diagnostics might offer a 'good enough' solution, and should be considered.
On Aug 6, 5:21 pm, Ayende Rahien <[email protected]> wrote: > 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
