First, log4j is a logging library for Java, and a very popular one at that. Basically, rather than just putting a bunch of print statements in your code, you can use log4j to handle logging in a highly structured and configurable way. The best thing about it is that you can sprinkle all sorts of logging statements in your code, and then turn most of them off when you have the bugs fixed and it’s time to deploy the application.
For a year now, my relationship with log4j has been completely harmonious. I’ve basically just used it to send all of its log messages to the console, and the only settings I’ve tweaked have been the log format (more detailed in the dev environment than in production) and what level of logging is turned on for various parts of my application. For example, I want to see every message for code I wrote, but only errors from external code that uses log4j (many Jakarta packages).
For about a week, I’ve been trying to take log4j to the next level. I’m trying to use the SMTP logger to have log4j send error messages from production to me via email, so I can find out things are broken before people start complaining about them. This ought to be relatively straightforward, but it has turned out to be a huge struggle, and frankly I’m a bit tired of it. log4j works like you’d expect it to — it’s easy to configure to do simple stuff, but your configuration can grow complex fairly rapidly. The problem is that the docs for log4j are poor, so it requires tons of trial and error work to figure out what’s going on. Then there’s the part where log4j seems to be behaving erratically, so I’m not sure whether the problems are due to my misconfiguration of log4j or something else.
I think that this may be the final straw that forces me to figure out how to run Tomcat within a debugger so that I can step through the log4j code and determine exactly what’s going wrong. I could abandon the whole project and leave things as they are, but that’s not my nature. One side benefit is that I’m strongly considering writing and posting my own guide to log4j just so I don’t forget everything I have managed to figure out.
Projecting civilian casualties
I’ve been trying to get myself not to post about Iraq any more, but as you can see, I can’t help it. Slate’s Fred Kaplan has written a story dismissing some projections of civilian casualties in Iraq when we invade. He makes the valid point that there’s no real way to tell how many casualties there will be, but then he provides a bunch of reasons why there will be fewer casualties than are specified in the projections.
One of his main reasons for predicting fewer casualties is that infrastructure will not be treated as a military target in this war, because we plan on rebuilding the country once we’re done. That, to me, seems very optimistic. I can believe that we won’t target infrastructure if we waltz through Iraq with little resistance (and if we do go to war, I hope that’s the case), but if we get bogged down at all and Iraq’s ability to resupply its army comes into play, you can bet that we’ll bomb any targets that will prevent supplies from getting to Iraq’s soldiers. It would be dumb to fight a war in any way other than that — holding back to preserve infrastructure when troops are dying and the war is not progressing would be foolish.
The other point is that our previous war with Iraq, a lot of the action took place in the middle of the desert. In this war, if things tilt toward the worst case scenario, we’re going to be doing a ton of fighting in urban areas. Needless to say, doing so could lead to a lot of civilian casualties, some of whom will die during the fighting, and other s who will die in refugee camps after fleeing ahead of advancing US forces.
Anyway, like he said, you can’t predict civilian casualties.