Logging In Enterprise Library

[itinsley]

Hi

Didn't know which group to post this in.

I am using Enterprise Library to (amongst other things) log XML
messages i receive through a Web Service. I recently had an error in my
config file declaring a Category with an incorrect name
"MessageCategory" instead of "MessagesCategory". Instead of raising an
exception when i attempted to log this message, it just did nothing
meaning that the application was running for a while without logging
any of these messages to file.

Is there any way of either:
a. finding out if a category exists from within your application
b. getting EL to raise an exception when a category doesn't exist.

I am using the following code to write the message.

LogEntry log = new LogEntry();
log.Message = message;
log.Categories.Add(logCategory);
log.Severity = severity;
Logger.Write(log);

This problem seems to me to be symptomatic of EL - that you put a huge
burden of responsibility in your configuration and as that
configuration differs in each of your environments, it is essentially
untested. So something that works fine in a test environment works
completely differently in your production environment - in this case
without even raising an exception. Does anyone have any comments on how
best to manage and reduce the risks in this area?

 

[Fred Morrison]

Write a unit test that tries to read all (or at least the most critical) keys from the config file
directly. True, you might end up misspelling the same XML tag twice (in the config file and the
unit test code), but if your unit test includes a verification step (e.g., make sure the output from
the LogEntry unit test contains the logged message), it might take some of the worry out of
deploying the application to production.

 

[itinsley]

Thanks Fred

i had considered something along those lines but as well as the risk
you mentioned (that's now 3 places i have to define a category - unit
test, .config file and code) i don't really want to have to run a
'unit' test in my production environment. Probably a better option
would be to locate the Category in my config file within the code at
run-time and raise an error if missing.

 

[Joerg Jooss]

Thus wrote (e-mail address removed),

Hi

Didn't know which group to post this in.

I am using Enterprise Library to (amongst other things) log XML
messages i receive through a Web Service. I recently had an error in
my config file declaring a Category with an incorrect name
"MessageCategory" instead of "MessagesCategory". Instead of raising an
exception when i attempted to log this message, it just did nothing
meaning that the application was running for a while without logging
any of these messages to file.
Is there any way of either:
a. finding out if a category exists from within your application
b. getting EL to raise an exception when a category doesn't exist.

No (at least Logger.ShouldLog() doesn't complain about unknown categories)
and no (heaven forbid).

But you can configure a trace listener that will be used for all unknown
categories. Thus, no log entry will get lost.

I am using the following code to write the message.

LogEntry log = new LogEntry();
log.Message = message;
log.Categories.Add(logCategory);
log.Severity = severity;
Logger.Write(log);
This problem seems to me to be symptomatic of EL - that you put a huge
burden of responsibility in your configuration and as that
configuration differs in each of your environments, it is essentially
untested. So something that works fine in a test environment works
completely differently in your production environment - in this case
without even raising an exception. Does anyone have any comments on
how best to manage and reduce the risks in this area?

Raising an exception in a logging framework is a horrible idea. You don't
want your logging framework to break your application in production because
of a typo...
Adding a trace listener as mentioned above should solve the unknown entry
issue.

You can also create a static class to better control your actual categories.

public static LoggingCategories {
public static readonly string Error = "Error";
public static readonly string Debug = "Debug";
}

Cheers,

 

[itinsley]

Raising an exception in a logging framework is a horrible idea. You don't
want your logging framework to break your application in production because
of a typo...

Well if the logging process we are talking about is a crucial part of
your application you would rather have it raising an exception than
"working" in a way that is not how it's supposed to work. If you make a
typo in a connect string you want your app to raise an exception and
you deal with it accordingly. I see this (for my context) as similiar -
if my app's not working as intended i would prefer to know about it
when i start it up and then fix it rather than be blissfully unaware it
is not working as intended until i find out some other way.

You can also create a static class to better control your actual categories.

i am using an enumerator - the app code is not the problem - it's the
configuration that can have the typos

Anyway, i like the solution you propose of having a Trace Listener to
handle unknown Categories (i can still write an error to the event log
if the Category is missing) but i can't find how to do this - could you
give me more details?

For the record you can get a list of Category Sources using the
following code:

LoggingSettings settings =
LoggingSettings.GetLoggingSettings(new SystemConfigurationSource());
NamedElementCollection<TraceSourceData> sources =
settings.TraceSources;
foreach (TraceSourceData source in sources)
{
Console.WriteLine(source.Name);
}


your help appreciated

regards


Ian

 

[Joerg Jooss]

Thus wrote (e-mail address removed),

Well if the logging process we are talking about is a crucial part of
your application you would rather have it raising an exception than
"working" in a way that is not how it's supposed to work.

But then I wouldn't call it logging. Logging is a operational necessity that
must not break.

If you make
a typo in a connect string you want your app to raise an exception and
you deal with it accordingly. I see this (for my context) as similiar
- if my app's not working as intended i would prefer to know about it
when i start it up and then fix it rather than be blissfully unaware
it is not working as intended until i find out some other way.

The difference is that connecting to a DB usually is a necessary step to
fufill some business logic, whereas logging isn't. If you need a guaranteed
write to some resource, a logging framework is likely the wrong tool.

i am using an enumerator - the app code is not the problem - it's the
configuration that can have the typos

Anyway, i like the solution you propose of having a Trace Listener to
handle unknown Categories (i can still write an error to the event log
if the Category is missing) but i can't find how to do this - could
you give me more details?

Sure. Fire up EntLibConfig.exe, open your .config file and expand the "Logging
Application Block" subtree in the tree view. Under "Special Sources", add
a trace listener reference to "Unprocessed Categories".

Cheers,