Just to point out, for NH Prof, merging log4net would actually make things a lot more complex.
On Wed, Aug 4, 2010 at 8:35 PM, 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 > >
