In order to use log4net with Common.Logging, the
Common.Logging.Log4Net assembly is required. Is it acceptable for
users to need to add a reference to Common.Logging.Log4Net to their
code? If this was unacceptable, the Common.Logging.Log4Net assembly
could be embedded in the NHibernate assembly directly. It seems that
the approach taken historically was to document the need for the extra
assembly reference and not embed anything.
I understand there is also sometimes a need to hook into the logging
layer independent of the logging provider being used. I propose that
there be an NHibernate LogManager class that is used all over the
NHibernate code to get an ILog instance. Providing log interception
at that point would be a simple matter of creating a class that
implements ILog and delegates to the underlying Common.Logging manager
but also throws events when messages are logged. The event mechanism
would be the same one powering events such as IPostLoadEventListener.
I assume some of the comments by Ayende were referring to NHProf...
would this design cover any needs there without significant
difficulty?
For the start-up configuration, after looking at the code, my best
interpretation of what Fabio said is that the log initialization code
should go at the start of BuildSessionFactory (before the call to the
proxy factory factory config). This would ensure that logging is
properly enabled during the initialization process.
I've already started re-integrating the old Common.Logging patch into
the trunk. I will work towards the design proposed here in the mean
time.
Patrick Earl
On Aug 2, 11:33 am, Fabio Maulo <[email protected]> wrote:
> Solution
> 1) add common logging
> 2) at NH startup look for log4net.dll (start-up mean just before instantiate
> the bytecode-provider)
> 2a) where present autoconfigure common-logging/NH to work with log4net
> 3) for other logging framework we can just relay to common-logging
> configuration/restrictions.
