Or several. It depends on how good of a model you want of a 'real' web server with separate web server and database, plus separate test system to drive the load. I wouldn't spend money for it from scratch, but if you already have recent hardware in a small form factor it would be worth considering.

Log4j supports selective logging. That means you can have info/debug/trace priority messages in place, but never see them in the log unless you explicitly enable extra logging for that class or package. You can do this at runtime, e.g., via something like 'chainsaw' (which attaches to a running process) or hooks in your UI.

Our policy is that logs are usually very quiet. Application startup/shutdown and not much more. But if there's a problem the debugging messages are already in place to let us peak into the system, even if it's been deployed to a production site.

BTW AOP is also great for this. You can configure logging interceptors that log activity when you're in a development environmnent, but easily removed in production. This is a natural approach when going from one layer to the next, e.g., when wrapping the DAO layer.

My first view of a Star Wars game was not exactly from the Star Wars realm, but rather it was "Star Raiders" for the Atari 2600. I think at that point in time there was huge copyright issues, but Star Raiders had a look and feel like the vector based star-wars game in the arcades (relatively speaking). It had a numeric keypad controller. Sometimes I felt like I was in the gunner room in the Millenium Falcon, shooting tie fighters.

The Atari 2600 version of Star Raider (singular, not plural) was a crippled version of the classic Atari 400/800 game. That was truly one of the best computer games of its era. I still remember physically ducking as the enemy torpedos slammed into my screen.

TheFrood