[Mono-list] log4net port to Mono !

[Nicko Cadell]

Jon,

Gert asked me to send you a quick reply.
My comments are inline:


> > First, the question: why use log4j over the existing .NET logging
framework -- 
> > the System.Diagnostics.TraceListener class (with hooks into the Trace,
Debug,
> > and Switch classes). The biggest difference appears to be that log4j
permits
> > "hierarchical" logging. I'm not sure I immediately see the use of it, 
> > but I'm sure it can be useful.

It is good to see that Microsoft have invested some effort in designing a
flexible and lightweight logging API. We have nothing against it. log4net
can even append events to the Trace system.

You have spotted the major design difference in log4X systems. That is they
support hierarchical decomposition of loggers and this results in a very
fine grained logging system.

log4j was originally designed when java debuggers were not really viable,
therefore all program debugging had to be done through logging. Therefore
the system is designed to support systems with a lot of internal logging.
Dumping out all the internal log messages will quickly overload the
developer, therefore fine grained control is required.

In java we now have good debuggers. In .net we have even greater debuggers.
But running apps in the debugger doesn't solve all the issues. There are
lots of times where the app cannot be run in a debugger, or the app cannot
be shutdown, or the environment cannot be simulated on a development
machine. In these cases having good logging baked into your application is
essential.

log4net supports dynamic configuration, the logging levels, appenders, well
everything can be adjusted at runtime. In many cases it is possible to
diagnose issues without terminating the process in question, that is
essential for some applications.



> > Most everything else appears (at a glance, I didn't look long) to be 
> > in .NET already.  This includes XML configuration files, and the ability
to 
> > log to various sources (Files, Streams -- and, by implication, sockets 
> > -- and the NET event log under .NET).  So why use log4j?

The Trace system is flexible in that it supports pluggable loggers. However
the api provided to listeners seems a little too lightweight and is slightly
obsessed with working out how much to indent a message.

There isn't a single solution that is right for everybody. log4net isn't
right for all applications, but competition and choice are good for
consumers.



> > This isn't a flame, I'm just curious.
> >
> > Second, my comments.  As suggested above, it would be a good idea to
provide a
> > link to the log4j documentation (or provide specific log4net
documentation) so
> > users don't have to go to apache and search for log4j.  Especially when
the
> > www.apache.org search engine provides incorrect results. :-)

We are acutely aware of the lack of any user documentation. It is something
we are urgently working on.



> > You also might want to investigate adding .NET features to the code.  
> > In particular, look up the Conditional attribute.  This would prevent 
> > you from having code like (taken from the FAQ):
> >
> >     if(log.IsDebugEnabled)
> >     {
> >         log.Debug("Entry number: " + i + " is " + entry[i]);
> >     }
> >
> > You could instead make "log.Debug" conditional on the symbol DEBUG:
> >
> >     [Conditional("DEBUG")]
> >     void Debug (string msg) {/* ... */}
> >
> > which would remove the "if" statement:
> >
> >     log.Debug ("Entry number: " + i + " is " + entry[i]);
> >
> > The call to "log.Debug" would only be present when the symbol "DEBUG" 
> > is defined by the compiler.

We looked and doing things like this. And indeed this is exactly what the
Trace system uses. One might think that the compiler was hacked to do
conditional method compilation just for the benefit of the Trace system.

The reason we don't use it is because the compiler will conditionally remove
the logging statement from the code at compile time. Therefore your logging
statement is gone. One of the key differentiators in log4net is that you
can, at runtime, dynamically, enable all your logging. None of your logging
is removed.

Performance wise the use of a guard if(log.IsDebugEnabled) is not too bad
(.net runtime seems good at that sort of thing). And the advantage of being
able to get every last logging message out of the code seems like a good
trade-off. 

Leaving in all the debug and trace logs does add to the code size, but CLI
apps are very small in comparison to traditional apps, and disks are cheap.
Even PDA have enough resources to cope. The benefits outweigh the costs.

Are there any other .NET features that we have missed out on?

Apologies if this is getting too off topic.


Thanks for your comments,
Nicko