Logging Abstraction

[Patrick Earl]

In my journey working to get NHibernate to work with the .NET client
profile, the only significant issue that remains (assuming NH-2263 is
accepted) is the logging framework. log4net has a dependency on
System.Web. There was previously discussion about logging
abstractions and using Common.Logging, but it seems that the
Common.Logging patch never got traction. Based on my reading of the
mailing list discussion it sounds like the preferred solution would
have no dependency on a third party framework and would feature an
NHibernate-specific pluggable logging system. Am I getting the right
idea?

Are there any other qualms people have had with the current logging
techniques, or would a pluggable mechanism for supporting an ILog-like
interface be good?

Patrick Earl

[Ayende Rahien]

That would actually causes issues for me.

log4net as a stable dependency means that I can use that to inspect the logs programatically. Having that moved to NH (of which I currently support everything from 1.2 to 3.0) would complicate things significantly.

Trying to build our own logging is going to be a complex endeavor, when you are talking about logging abstraction, I presume that you mean introducing ILog specific interface, and not really build our own logging

What I suggest is that instead of having a hard dependency on log4net, we will turn that into a dynamic dependency, we will check if the dll is present, and if so, we can bind to it dynamically. 

The problem with doing that is that this is what common.logging already does, so I am not sure where we gain something here.

[Patrick Earl]

For myself, I'm not particularly opinionated in any direction other
than the direction that will allow for client profile support. If
this happens through a custom pluggable logging layer, common.logging,
or some other way, I'm happy. It seems like the common.logging
library is a good fit, but it's not already on the trunk so I'd be
curious to know why.

The last log4net release was in 2006 and the mailing list is pretty
quiet in terms of "getting it done" type traffic. It also seems like
over time there has been not insignificant demand for the ability to
use a different logging framework. Using something like
Common.Logging seems like a good way to solve the problems with the
client profile dependencies and the different logging framework
support.

I don't think that replacing log4net with Common.Logging is like
trading one "evil" for another. Common.Logging has a much smaller
footprint than the actual logging frameworks and was designed to solve
the pluggable logger problem. If this is what is desired for
NHibernate, why not utilize the work of others? On top of this, there
is already a patch to implement this change in NHibernate.

I'd very much like to have this issue pushed to completion. If it
involves additional development, testing, or documentation time, I
would be happy to volunteer my time. I just need to know where to put
my energy.

Patrick Earl

[Fabio Maulo]

Patrick,

Are you sure that the client-profile-support is so fundamental ?

So far you are the only one talking about it.

Before begin a big work in NH-3 I would be sure about how much important is the client-profile-support for NH future.

--
Fabio Maulo

[Craig van Nieuwkerk]

I think client profile will become much more important in the future.
It is only just becoming used frequently with .NET 4 and I suspect
most desktop applications will soon prefer it. If the work required
doesn't require major rewriting I would say go for it, especially if
Patrick is happy to do most of the leg work.

Craig.

[Michael Maddox]

I would like to see client profile support in NHibernate.

Just as a data point, the castle project has already started to
embrace the client profile.

Microsoft is pushing client profile pretty hard. The VS2010 Console
Application wizard defaults to client profile. I believe Windows
Update defaults to providing the client profile for .NET 4.0.

The client profile is good for developers and makes deployment of the
.NET framework smaller and easier.

-Michael Maddox
http://www.AgilityForORMs.com/Home/Products

[David Pfeffer]

I personally find the client profile support extremely important -- once its available, I'll immediately begin using it. NHibernate is my only dependency forcing me not to use the client profile.

[Fabio Maulo]

The place to vote for issue fix is our JIRA

http://216.121.112.228/browse/NH-2263

Thanks.

Here we can discuss about some "long" implementation details.

--
Fabio Maulo

[Richard Brown (gmail)]

Presumably there's no logging work for us to do if log4net can target the ClientProfile too?

 

https://issues.apache.org/jira/browse/LOG4NET-233

[Fabio Maulo]

Yes Richard you are right but:

date of issue 2009/09/19 and Original estimate 168hs and 10 votes

I don't think we will see it fixed for NH3 release.

--
Fabio Maulo

[Fabio Maulo]

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.

--
Fabio Maulo

[Patrick Earl]

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

[Fabio Maulo]

We need the Log before start anything else.

The discussion about CommonLogging and custom log was part of that old discussion.

I'm inclined to say goodbye to any external reference (including Iesi... even if not so "external") but, at this point, for logging we will reinvent the wheel.

If, using CommonLogging, we don't loose something important for NH then we can use it.

--
Fabio Maulo

[Fabio Maulo]

Perhaps I was not clear...

"at NH startup look for log4net.dll (start-up mean just before instantiate the bytecode-provider)"

That mean before anything else.

Before BuildSessionFactory NH have done ton of work.

--
Fabio Maulo

[Erich Eichinger]

Hi all,

 

I am one of the authors of Common.Logging. If you are missing something in Common.Logging, please let us know. I already had some discussions around Common.Logging+NHibernate with Fabio and Oren long ago, I believe there were some needs regarding logging context?

 

As sourceforge is a big PITA, we recently decided to move over the project to github, hopefully encouraging more people to contribute. Also we will move the mailinglist and bugtracker, I will communicate the changes asap (by the end of next week).

 

As for introducing an external dependency, I fully understand your concerns. 2 thoughts on this:

 

1) there seems to be a misconception: When using Common.Logging there is only a dependency on Common.Logging, but *no* compile-time dependency on log4net. Only if you configure Common.Logging to use log4net (by specifying Common.Logging.Log4Net's LoggerFactoryAdapter in App.config) you obviously have a *runtime* dependency on log4net.

 

2) As for avoiding any dependency on a logging framework at all, I'd love to hear any ideas out there how to allow for using a logging framework without introducing a compile-time dependency. My only idea would be to hijack the existing System.Diagnostics.Trace API, providing TraceListeners for plugging in the logging framework of your choice.

As for  migrating from log4net to System.Diagnostics, I attached a simple POC demonstrating the idea for introducing a log4net-compatible logging infrastructure. This should make the migration pretty much a no-brainer.

I plan to conduct some performance-tests as well as tests regarding the functional behavior - especially regarding maintaining the correct stacktrace in the logs - after moving the project on github to see if this idea makes sense. Any feedback is welcome!

 

hth,

Erich

 

From: nhibernate-...@googlegroups.com [mailto:nhibernate-...@googlegroups.com] On Behalf Of Fabio Maulo
Sent: 04 August 2010 11:37
To: nhibernate-...@googlegroups.com
Subject: Re: [nhibernate-development] Re: Logging Abstraction

 

We need the Log before start anything else.

[Fabio Maulo]

I was looking for you in Skype few minutes ago...

I have to go now, I'll back in few hours and I will open another thread to let you know my thoughts about NH and external references.

--
Fabio Maulo

[Patrick Earl]

Hi Erich.

Nice to hear from you. While I'm fairly new to the NHibernate logging
world, it seems that it would be very useful to attach a lightweight
log monitor in a logger-independent manner. For example, regardless
of the full logging framework being used, you would be able to
register a handler that fires an event whenever it sees appropriate
log messages. This would allow code that uses information from the
logs to attach itself easily and get that information, no matter what
the user has selected for their own logging framework.

I imagine something like:
RegisterLogMonitor(CallbackFunction, LogLevel.Warn, "My.Log.Name")
A similar mechanism should be provided that works with the config
system. The name of the log to watch would be optional.

The callback function would have a signature something like:
CallbackFunction(string logName, LogLevel level, string message,
Exception exception)

Using this lightweight mechanism, programs would be able to register
watchers for certain log event types and presumably the Common.Logging
framework would have some high-performance way to pass along only the
logs that are requested and ignore others. This mechanism would
ignore any logging levels configured for other software. This would
allow somebody who needs to monitor the logs for some programmatic
reason to trust that their needs will be satisfied no matter how users
configure the primary logger.

I started on such an implementation already, but it'd be great to just
use something available in Common.Logging if you have the time to work
on it now.

Patrick Earl

>  LoggingTest.zip
> 1KViewDownload