Brian Sherwin's Blog

Moving at the Speed of .Net
posts - 98, comments - 62, trackbacks - 30

My Links

News

Twitter












Tag Cloud

Archives

Links

Tuesday, December 02, 2008

IBM XML Contest

While I am not always all that interested in IBM DB2 XML contests, this one interested me because I collect Rubick's cubes. I probably have 50 different cubes from 6 sided to a 12 sided puzzle that works on the same principles of the Cube.

Anyway, I may have to enter just to increase my chances of getting another Cube.

Check it out over here...you could win a 32GB iPod Touch!

http://antoniocangiano.com/2008/12/01/ibms-xml-challenge-lots-of-prizes-inside/

 

  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati

Posted On Tuesday, December 02, 2008 10:14 AM | Feedback (1) |

Tuesday, July 15, 2008

When to check IsDebugEnabled when using log4net

I see this a lot in projects that I have been involved in where the code goes something like this:

if (log.IsDebugEnabled)

log.Debug ("Connecting to Database");

conn.Open();

or something similar when calling the other logging methods (Warn/IsWarnEnabled, Error/IsErrorEnabled, etc)

Here's the point of this short post...you only need to check the log setting if what you about to do is time consuming.  For example, if you are going to walk through a collection of objects and get a list of ID's that you are about to process and you want to output that to your log, check the flag.

Checking the flag before you do something short and piddly...waste of time. Look at the log4net code. You'll notice that the methods will check the flags for you.

Technorati Tags: ,
  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati

Posted On Tuesday, July 15, 2008 10:43 PM | Feedback (0) |

Thursday, February 21, 2008

Watch your procedure cache when using parameters

Dan Guzman had an enlightening post on how SQL server caches ad-hoc queries when using inline parameters.  Basically the gist is that if your values for any given paramter changes you get variability in you cached procedure.  However, if you specify the SqlDbType when adding your parameters, you can avoid this whole problem.

Technorati Tags:
  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati

Posted On Thursday, February 21, 2008 5:30 PM | Feedback (0) |

Friday, February 15, 2008

Moving your Log4Net configuration out of web.config with ASP.NET 2.0 web sites.

I was working with log4net recently and had put a lot of the configuration information in the web.config file for an ASP.NET 2.0 web site.  Ideally, this was not what I wanted because I want to be able to change the configuration of the log4net without recycling the web application (a side effect of changing the web.config file).  After spending a fair amount of time reading out on the web--a lot of people said it can't be done. It took me piecing together multiple settings to finally get this to work.

However, I have the following dilemmas:

  • First, I didn't find all of the information in one place.
  • Second, I didn't bookmark the information I did find to give proper credit where it is due.

Therefore, if this has a resemblance to your work--I'm sorry--but I wanted to write this post to put it all in one place.

So my goal was to put it here in one place.

Step 1:

Create the log4net.config file.  That's right, break out the configuration into a file (call it whatever you want, but I call it log4net.config). Copy all of your log4net configuration settings out of your web.config file and put them here. (Don't just copy and paste--cut out everything related to log4net from the web.config file).

 

<?xml version="1.0"?>
<log4net>
  <appender name="UdpAppender" type="log4net.Appender.UdpAppender">
    <remoteAddress value="127.0.0.1" />
    <remotePort value="8080" />
    <layout type="log4net.Layout.XmlLayoutSchemaLog4j">
      <locationInfo value="true" />
    </layout>
  </appender>
  <root>
    <!-- OFF, FATAL, ERROR, WARN, DEBUG, INFO, ALL -->
    <level value="ALL" />
    <appender-ref ref="UdpAppender" />
  </root>
</log4net>

Step 2:

Tell the application to configure log4net using this config file. There are really two spots for this. First, the global.asax and second the assemblyInfo.cs file. Note, that most of the time you will start out with a global.asax file with all of the code inline. For whatever reason, the only way I could get this to work was to break the global.asax up to use a code-behind and then ass the assemblyInfo.cs file.  So it ends up looking like this.

global.asax:

<%@ Application Language="C#" Inherits="GlobalAsax" %>

global.asax.cs (in your App_Code folder):

using System;
using System.Web;

public class GlobalAsax : HttpApplication
{
    // you may have lots of other code here
    void Application_Start(object sender, EventArgs e)
    {
        log4net.Config.XmlConfigurator.Configure();
    }
}
Now that you have your application calling log4net's configuration, you can set an attribute in your assembly info so that log4net knows where to look for the configuration file.

AssemblyInfo.cs (in your App_Code folder):

[assembly: log4net.Config.XmlConfigurator(ConfigFile = "log4net.config", Watch = true)]

The watch flag tells log4net to keep an eye on the configuration file for potential changes.  This is helpful if you want to change the configuration from logging everthing to errors only during the middle of your testing.

Step 3:

Log to your hearts content! Now that you have your configuration set up, start logging everything from Information to Debug to Fatal Errors. This sure beats doing "Response.WriteLine"

BTW, the reason I posted the UdpAppender, was that I have found this one to be incredibly useful when using Apache's "Chainsaw" log reader to view your logging without having to keep searching through log files.

Technorati Tags: ,
  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati

Posted On Friday, February 15, 2008 12:43 PM | Feedback (8) |

Powered by: