That behavior is there because 95% of users does not know the pretty new feature (no specific logging-framework dependency) and they are using log4net or NH-Prof. If you change the behavior please mail Ayende because he may have to find a solution for NH-Prof.
On Wed, Feb 8, 2012 at 4:02 PM, Oskar Berggren <[email protected]>wrote: > 2012/2/8 Rafał Kłys <[email protected]>: > > Hi, it was my pull request. I understand issues with Assembly.Load, and I > > have another idea. Check > > https://github.com/nhibernate/nhibernate-core/pull/73. > > > > This time it checks if log4net is already loaded in current AppDomain > (using > > AppDomain.CurrentDomain.GetAssemblies()). If someone uses log4net, it > will > > be loaded and it doesn't matter now if NH or log4net is in GAC or not. > Only > > problem with this is if someone first initializes NH, and log4net > > afterwards, but it's a bug IMO: logging should be initialized first > always. > > > > > Hi Rafał, > > Thanks for working on this. However, I see some issues with this > patch. I agree with you that logging, if used, should be initialized > first, but I also fear that this behaviour could lead to strange and > difficult to debug problems, where it may not be obvious why logging > doesn't work. > > In fact, when I think about it I have to wonder if this special case > automatic-but-only-if-in-a-specific-directory loading of log4net is > really necessary. Perhaps we should rip that out as a breaking change > in the upcoming 3.3 and *require* even log4net users to set the > nhibernate-logging application setting. It's certainly not difficult. > > To be clear: My idea is to *keep* the log4net logger factory to make > log4net use easy, but *require* setting nhibernate-logging="log4net" > to turn it on. In this case, we wouldn't care where the assembly is > located, as long as the runtime can find it. > > > /Oskar > -- Fabio Maulo
