Extending Logging.Database

Topics: Logging Application Block
Aug 2, 2007 at 7:15 PM
I'm designing a system wherein I'm logging the number of hits, source IP address and response time to particular pages. I've started off using the Logging Block and planned on extending the block where necessary. So far, I've found I'll need to inherit from LogEntry to add the three additional fields (hits, IP, response time), updated the Template to include the new properties as well as update the LoggingDatabase.sql to create tables that include the attributes and a stored procedures to store the data there and, finally, update the Logging block code to ensure the correct procedures are called etc.

It's starting to feel like I'm trying to fit the beautiful round peg of the Logging Block into to the square hole of my application. I began leaning towards the Logging Block because of the configurability and the relative ease with which we could transition to other Trace Listeners (e.g. MSMQ).

Is there an easier way to log extended logevent properties to a database or is it time to implement a straight-to-database approach?

I know design questions are always answered with "it depends", but hopefully there's enough information to go on here.

Thanks for any help.
Aug 4, 2007 at 2:43 AM
One idea, totally untested and off the top of my head, but with minimizing changes to the stock EntLib in mind :

At Design-time:

  1. Define a formatter who's implementation formats [only] the LogEntry's "extradata" into some structured format you would be comfortable parsing in SQL. Either create a custom formatter or customize the template of a TextFormatter if you consider it reasonably parsable.
  2. Configure this formatter on the vanilla database listener. This should result in formatted extradata when logging, without changing default listener code.
  3. Modify the WriteLog stored proc to parse the FormattedMessage parameter, extract the (hits, IP, response time) extra data from this parameter and push them wherever you want in the DB.

At Run-time

  1. Add your extra fields (hits, IP, response time) to the ExtraData property on the stock LogEntry object.
  2. Logger.Write( logEntry )

If you want more control, I'd recommend just creating your own custom database listener.
Aug 7, 2007 at 3:22 PM
By "extradata" I assume you mean ExtentedProperties? Or do you mean the custom subclasses properties? If you do mean the ExtendedProperties, how can I access those in the template? The ReflectedPropertyToken only works for first class properties, correct?
Aug 7, 2007 at 3:43 PM

You can use the "keyvalue" token in your template.

Aug 7, 2007 at 4:56 PM
I've used the following token for showing extended properties in a text template if you want to go that route:

{dictionary({key} - {value})}