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
>
>

Reply via email to