Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / New Users / January 2007

Tip: Looking for answers? Try searching our database.

Logging In Enterprise Library

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
itinsley@gmail.com - 18 Jan 2007 04:18 GMT
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 - 18 Jan 2007 12:02 GMT
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.

> Hi
>
[quoted text clipped - 27 lines]
> without even raising an exception. Does anyone have any comments on how
> best to manage and reduce the risks in this area?
itinsley@gmail.com - 18 Jan 2007 23:54 GMT
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.

> 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.
Joerg Jooss - 19 Jan 2007 19:48 GMT
Thus wrote itinsley@gmail.com,

> Hi
>
[quoted text clipped - 10 lines]
> 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.
>
[quoted text clipped - 10 lines]
> 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,
Signature

Joerg Jooss
news-reply@joergjooss.de

itinsley@gmail.com - 21 Jan 2007 22:53 GMT
> 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 - 23 Jan 2007 06:54 GMT
Thus wrote itinsley@gmail.com,

>> Raising an exception in a logging framework is a horrible idea. You
>> don't want your logging framework to break your application in
[quoted text clipped - 3 lines]
> 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.

>> You can also create a static class to better control your actual
>> categories.
[quoted text clipped - 6 lines]
> 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,
Signature

Joerg Jooss
news-reply@joergjooss.de


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.