EIF vs log4net
Note: this entry has moved.
I've been doing a comparison of both products recently. Before you read, I must say that I used log4net a lot (I even appear as a contributor :o), so I may be biased. On the other hand, I only evaluated EIF, looked at how it's used in a real world product, and read the documentation provided, as well as built the examples.
Here are my conclusions.
Conventions:
·
x: feature is supported equally.
·
-: feature is supported/implemented, but is not as
good as the other product
·
+: feature is better supported/implemented than the
other product
|
Feature |
EIF |
log4net |
|
General |
||
|
Decoupling of event source and event
sink |
x |
x |
|
Arbitrary target event sinks |
x |
x |
|
Number of built-in event sinks
supported |
3 |
20 |
|
Extensible |
x |
x |
|
Configuration |
-
(quite complex) |
+
(very simple) |
|
WMI supported built-in |
x |
|
|
Arbitrary log data |
+ |
-
(built-in just text) |
|
Multiple logging "domains" (ability to
configure the framework by modules, i.e.
each logical feature has its own config,
repository and sinks) |
|
+++
(a BIG plus for highly composed and
pluggable apps) |
|
Installation |
-
(mostly requires admin permissions) |
+
(xcopy) |
|
Support |
? |
x
(excelent peer support) |
|
Source provided |
|
+ |
|
Supported Platforms |
.NET |
.NET, CF, Mono, SSCLI |
|
|
|
|
|
Runtime |
|
|
|
Performance with logging enabled |
x |
x |
|
Performance with logging disabled for a
certain event |
- |
++
(orders of magnitude faster) |
|
Reconfiguration |
-
(only possible with WMI or Windows
Trace) |
+
(full configuration monitoring &
reloading) |
|
|
|
|
|
API - Dev friendliness |
|
|
|
Event (source) categorization |
-
(uses the event Type. leads to increasingly
big hierarchies of event types) |
++
(combination of log level + logger name
-dotted notation-) |
|
Event source inheritance |
|
++
(filters and sinks applied to all
descendant sources) |
|
Customization |
x |
+
(everything) |
|
|
|
|
One of the "distinguishing" features of EIF is
request tracing, but it is mostly irrelevant as it
only works using the remoting CallContext, which
reduces its applicability considerably. And remoting
is not a long-term platform to rely on either... For
request-like tracing on a single thread (important
when there're multiple components involved in an
operation happening on a single machine/thread)
log4net offers similar functionality through its
Nested Diagnostics Context.
For business events that rely on arbitrary objects
being send, EIF has a clear advantage. I wonder,
however, how many business notification scenarios
are actually handled through logging... Through
customization similar functionality could be
implemented in log4net, however.
Overall: both seem like good logging packages. EIF may be
more manageable as it has strong relationship with
WMI. log4net, on the other hand, clearly wins on
simplicity and in my opinion satisfies most common
logging and tracing needs.
Except for the extra WMI stuff (which can also be
implemented as custom extensions to log4net - I've
done it) and arbitrary objects publication (also
achievable, but requiring more work), I'd choose
log4net.
Side Note
log4net "event source" (loggers): in log4net, you ask for a logger to the
LogManager. Using a simple dotted syntax, you create
hierarchycal loggers that inherit sinks, filters and
threshold very easily. For example, the following
code asks for a logger and logs an informational
message:
ILog log = LogManager.GetLogger("Finance.Accounting.Customers.Administration");
if (Log.IsInfoEnabled)
{
log.Info("Adding user " + _userId);
}
some other component in the same module may use the
following:
ILog log = LogManager.GetLogger("Finance.Accounting.Orders");
if (Log.IsInfoEnabled)
{
log.Info("Adding order " + _orderId);
}
All the "Finance" application, or the "Accounting"
module can be configured in a single place, and
affect both components. A common use is to pass the
current component type to the GetLogger() method,
therefore making the logger match class full names,
which is also an easy way to configure groups of
components or modules in an application. For
example:
<!-- Enables all logging events in finance application (both components above) -->
<logger name="Finance ">
<level value="ALL" />
</logger>
<!-- Enables INFO logging events in accounting module (both components above) -->
<logger name="Finance.Accounting">
<level value="INFO" />
</logger>
<!-- Enables INFO logging events in Orders module (only for the last code above) -->
<logger name="Finance.Accounting.Orders">
<level value="INFO" />
</logger>
Custom logger levels can be used directly, without
previous definition, for example "BusinessEvent" or
"CriticalOperation". This functionality, combined
with hierarchycal loggers is very flexible and
completely removes the need in EIF for defining
custom types for every event. In addition, arbitrary
key-value (only strings) can be logged by using a
so-called Mapped Diagnostics Context. Functionality
similar to request tracing in EIF is available
through Nested Diagnostic Context, that is
threads-specific.
I'd love to hear arguments in favor of EIF. I may
be missing some other features it has to offer, or I
may have misunderstood some of its functionality, as
(like I said) I haven’t used it before.
Have you used both products? What do you think
about the points made above?