ROTFL!!! You don't have to stop. On Wed, Aug 4, 2010 at 7:04 PM, Jason Dentler <[email protected]>wrote:
> IMO, this big breaking-change feature missed the cut-off date for NH 3. > > There is already dll-shock when EF people wander over to NHibernate. Don't > add more DLLs without a good reason. I'm not sure if client profile > support qualifies as a good reason. > > Please decide fast. I may need to stop the presses. > > > On Wed, Aug 4, 2010 at 3:08 PM, Fabio Maulo <[email protected]> wrote: > >> LOL!! >> I said " log4net adapter" not log4net itself ;) >> >> On Wed, Aug 4, 2010 at 4:44 PM, Ayende Rahien <[email protected]> wrote: >> >>> 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 >>>> >>>> >>> >> >> >> -- >> Fabio Maulo >> >> > -- Fabio Maulo
