Sharing a little programming know-how…

Archive for September, 2011

Starting and Stopping Tomcat on Windows

Using schedule tasks and group policy editor, you can start and stop a Tomcat server on Windows startup and shutdown. I had to search for this a couple of times. First when I discovered it and then again when I needed to reproduce the rules on another machine. I’m not crazy about running tomcat as a service under Windows, particularly because I was running into permission problems with my particular web application. Depending on what you are trying to do, this may not be an issue. I was interacting with the filesystem and executing Python scripts from within my servlet. There’s probably a proper way to run as a service and provide all the security credentials required for what I was doing, but I found the method I came up with much more simple.

So, the method is pretty simple. Using the provided startup.bat and shutdown.bat batch scripts provided with the tomcat distribution, you’ll execute these scripts upon system startup and shutdown within Windows. The methods for doing each differ, but they achieve the same effect.

Okay, so on system startup, you’ll be creating a scheduled task. Here are the steps…

  1. Navigate to Start -> Control Panel -> System and Security. Under Administrative Tools, click the “Schedule Tasks” link. This opens the Task Scheduler dialog.
  2. We’ll be creating a task to run the startup.bat script foud in the bin folder of the Tomcat distribution. If you need help on how to create a task, use the Help menu in Windows. It will provide a much more thorough explanation than I’m willing to spend time writing. I’ll briefly hit on any settings I changed from the defaults.
  3. Under the first tab “General”, you’ll need to name your task and select the account you’ll use to run the task. I selected an account belonging to the Administrators group and selected the option to have the task run whether the user is logged on or not. I also selected the option to “Run with highest privileges”. I DID NOT select the “do not store password”.
  4. Under triggers, click New and then select “At startup” for when to begin the task. That’s it.
  5. Under actions, click New and the Browse. Navigate to your Tomcat install directory and select the startup.bat script under bin. I chose to set the “Start in (optional):” value to the same directory as the startup script.
  6. I did not change any options under the Conditions tab.
  7. Finally, under settings you’ll want to unselect “Stop the task if it runs longer than:” and “If the running task does not end when requested, force it to stop”. You’ll soon see that this task just starts up another process and exits

That’s it for starting up Tomcat. You could stop here, but when Windows is shutdown, Tomcat will be forcefully stopped and if you have any code designed to do cleanup on server shutdown, it won’t be executed. This part is not as obvious.

  1. Using the Group Policy editor (Run -> gpedit.msc), you’ll simply add the Tomcat shutdown.bat script to the list of scripts that run on shutdown.
  2. On the left hand hierarchy view, select “Local Computer Policy” -> “Computer Configuration” -> “Windows Settings” -> “Scripts (Startup/Shutdown)”
  3. From here, open the Shutdown properties and then add the shutdown.bat script to the list (if any other scripts are present).

You might be thinking, “Why not add the startup.bat script to the startup properties?” For one thing, you won’t have any say as to which account runs the startup script. It runs as System and that’s it. Secondly, if you need to shutdown Tomcat and perform maintenance, you’ll either have to manually startup Tomcat, which will leave you with a command shell for the running process you’ll have to be very careful about not closing, or reboot the system. With the Task Scheduler, you can rerun the task “On Demand”, which will start the Tomcat server under the Task Engine service and you will not see it while logged on to the system.


Version Control Everywhere

Version control seems to be everywhere I look these days. The number and variety of version control systems prompted me to write this article. Of course, you can always consult Wikipedia’s article on Version Control for more up-to-date information.

I code a lot in Java, which is a fairly open language although since Oracle’s acquisition of Sun Microsystems and subsequently the intellectual property of the Java language it is becoming less so. I mean one of their first actions after the acquisition was to sue Google over the use of Java in the Android operating system. I digress. That’s a whole other topic. My point is that Java is used in lots of open source projects and by consequence these are typically managed by some type of version control.

How many have I come across in just the past few months you ask? Let me count the ways:

  • There’s SVN, which has gained considerable popularity as the defacto version control system for Google Code
  • There’s Mercurial, which I’m not familiar with but is used by a few open source projects I’ve checked
  • There’s Maven, which is project management framework with version control built-in
  • There’s Git, which again, I’m not really familiar with but it’s used in some projects I’ve come across
  • Lest I forget the granddaddy of them all, you’ve got CVS as well if you are feeling nostalgic

Of these, Maven is probably not a true version control system. But when discussing projects managed with Maven, you’ll hear “repository” used a lot, but “checkout” not so much. I’m also not saying these two words alone describe a version control system. Geesh, lighten up! This article’s being written for fun.

Okay, so all these version control systems are out there including many more proprietary systems… check the Wikipedia article for a full list. So what? My real gripe is having to learn all these systems to work with the various open source projects. And then, learning is not even so bad. It’s having to download and install the clients for each one of these systems. It would be nice if someone developed a universal version control client that could interface with all the different systems out there… Oh wait, someone’s doing that too! Check out Amp, a fledgling universal version control system.