For a long time now, a few of my co-developers have been trying to figure out what caused this trap in WSAD:

Type=GPF vmState=0xffffffff
Target=20030915 (Windows XP 5.1 build 2600 Service Pack 2 x86)
ExceptionCode=0xc0000005 ExceptionAddress=0x1000ac84 ContextFlags=0x0001003f
Handler1=0x111016c0 Handler2=0x10019730
Module=c:\WSAD512\runtimes\base_v51\java\jre\bin\j9vm21.dll
Module_base_address=0x10000000
Offset_in_DLL=0x0000ac84
EDI=0x0011d9c8 ESI=0x008e5e60 EAX=0x74753f3e
EBX=0x0011d9c8 ECX=0x03b5cf14 EDX=0x7463656a
EBP=0x000be300 ESP=0x04381644 EIP=0x1000ac84
Generating crash dump: C:\Documents and Settings\c09974\j9.dmp

I had a quick look a while back, and couldn’t see anything obvious, and my WSAD was working OK, so I didn’t spend too much time on it Anyway, yesterday I found that I was in the same position, and the only thing that had changed on my machine was that I had installed Mercury Interactive QuickTestPro.

Not being able to have my server running in debug model with hot-swap turned on was completely unacceptable, so I spent a bit of time trying to track down what the problem was.

Luckily, I was only temporarily installing QuickTestPro to help another colleague, however, the problem remained even after I had uninstalled it! Yikes!

So, I used a copy of ListDLLs from SysInternals to see what DLLs were in use at the time of the dump. I then compared that list to the list of DLLs in use on a colleague’s machine that wasn’t dumping. The only difference between was a file called c:\windows\system32\micsupp.dll. Doing a hexdump of that DLL gives me a few clues such as the following strings:

micsupp.dll
ClassLoadHook
JVM_OnLoad
SOFTWARE\Mercury Interactive\Java Add-in\Modules


Lovely! It looks like Mercury is mucking around with my default Java installation. I tried to renamed the dll to something else, but then I can’t even start WSAD! So, what to do? Perhaps it didn’t uninstall properly, so I had a look at the c:\Program Files\Mercury Interactive\QuickTest Professional\dat directory. In there, I found a bunch of uninstaller files that I tried to run by using the following command:

\windows\miuninst6.exe miuninst.ini
\windows\miuninst6.exe QTP65P13_NS702_SUPPORT.ini
\windows\miuninst6.exe QTP65P16.ini
\windows\miuninst6.exe QTP65P63.ini
\windows\miuninst6.exe QTP65P84.ini
\windows\miuninst6.exe QTPJAVA65P08.ini


However, that still didn’t solve the problem! However, I did find a file called install.log in that directory that contained (amongst other stuff):

Installing Standalone VMs (JDK/JRE/Oracle1.3.X/Netscape 6)
[
  Copying micsupp.dll from C:\Program Files\Common Files\Mercury Interactive\SharedFiles\JavaAddin\bin to C:\WINNT\syste
m32\
  ...succeeded (return value is 0 )
  Adding _classload_hook environemtn variable
  Adding _JAVA_OPTIONS environemtn variable
]

Based on this, I thought that perhaps I should check my environment variables. Looking at those, I found that Mercury Interactive had created the following environment variables:

_classload_hook
_JAVA_OPTIONS
CLASSPATH
IBM_JAVA_OPTIONS
LSERVRC
MIC_CLASSES


So, I just removed them all, and believe it or not, WSAD started up with no problems, and I could now resume debugging with hot-swap. Thanks so much Mercury Interactive for such a quality product – not!!

Now, fortunately for me, I don’t actually need the Mercury Interactive QuickTestPro product on my machine, so I am confident that this fix won’t affect my normal operation. However, if you need to use QuickTestPro, I am not sure what affect removing these environment variables will have on your installation.

I used to use the sysdeo Tomcat plugin in Eclipse for my development, but someone suggested that I take a look at the Eclipse Web Tools project, which is an application server feature for Eclipse. It seems like it is the mechanism through which Eclipse is planning to support application servers in the future, so I thought it would be worth a look.

However, once I got it installed, I ran into a problem that is mentioned a few times on various sites on the web, but with few solutions. When I tried to run the application server, I got the following message:

Due to new licensing guidelines mandated by the Apache Software Foundation Board of Directors, a JMX implementation can no longer be distributed with the Apache Tomcat binaries. As a result, you must download a JMX 1.2 implementation (such as the Sun Reference Implementation) and copy the JAR containing the API and implementation of the JMX specification to: ${catalina.home}/bin/jmx.jar


This article describes the workaround that I discovered to make Tomcat 5.0 work correctly inside Eclipse.

But first, let’s step back to find out how I arrived at my current state.

From the Eclipse Web Tools home page, they have a link on the top-right hand side that takes you to the latest download page. For me, I used Version 1.5.2 of the WTP.

On that page they conveniently provide a link where you could download, in one thumping big file, a single zip that contains Eclipse 3.2.1, WTP 1.5.2 and all the other pre-requisites (beware, it is about 200MB!)

On my Ubuntu machine, I originally installed eclipse using apt-get, which installs into /usr/share/eclipse. To preserve all my existing shortcuts, I just renamed that directory to be /usr/share/eclipse3.1, and unzipped the new eclipse into /usr/share/eclipse. I am not really sure if that is the sanctioned way (probably not), but it worked perfectly for me.

Before you create a new project, you will need to go into the Windows/Preferences menu item, and open the Server settings dialog. In here, add a new Server Runtime for Tomcat 5.0 and point it to your default tomcat directory (/usr/share /tomcat5 for me).

From there it was a simple matter of creating a new Dynamic Web Project, where it asks me which “Target Runtime” I wanted to deploy into, and I chose the newly created Tomcat 5.0 runtime.

I then developed a simple web application, and when I attempted to start the Tomcat instance, I got the above error message. Searching on the web didn’t give me too much love, and interestingly, I don’t get this message when I start Tomcat using /etc/init.d/tomcat.

Anyway, the solution I found was to edit the runtime classpath of the application server (from the Run/Run… menu) to include the following entries:

Once I applied those changes, and restarted my application server, everything was working like a champion.

I was looking at re-skinning a sporting team website that I had recently created, and really liked the look of the new rounded corners that grace so many websites. There are two main techniques that are used to achieve that look:

1. Having a number of 1×1 pixel divs that shape the corners
2. Having some rounded corner images

I don’t really like the first technique because it seems so inefficient (not to mention that it reminds me of the 1×1-pixel fillers of the 90’s), and the second wasn’t able to be used for my purposes because each team on my website can pick their own colour scheme from the full 24-bit RGB colour space (and I didn’t want to have to create 16777216 different corner combinations). So, what to do?

Generating Images Dynamically

I got thinking about whether I could generate the images programmatically. Looking at a very simple corner image up close, they really are quite simple and I figured that I could write a very simple image generator where the image shape was hard-coded, but where the colours could be substituted in at runtime. Initially I thought that I would use the Java2D imaging libraries, but when I stopped to consider that each page would probably have 3 or 4 sections that are bounded by rounded corners, that would mean that I would be creating 12-16 images for each page load. Whatever technique I used would have to be very lightweight and fast. To top it all off, I also wanted to support transparency in the images so that my rounded corners could overlay on a background colour nicely.

It seemed to me that PNG was an excellent choice for a graphics format. It is a simple format, handles transparent pixels, and has pretty good support from all common browsers (with the exception that IE5 and IE6 cannot (natively) handle partially transparent images). Given that most corner images are quite small (say, 10 by 10 pixels) I thought I would write a PNG generator that takes an array of, say, 100 values that represent the red, green, blue and transparency values for each pixel. To create an 5×5 image that looked like (zoomed to 15×15 for clarity) would look like:

	// A 5x5 image with each line being
	// red, green, black, black, black respectively
	byte[] data = new byte[] {
		(byte)255, (byte)0, (byte)0, (byte)255,
		(byte)255, (byte)0, (byte)0, (byte)255,
		(byte)255, (byte)0, (byte)0, (byte)255,
		(byte)255, (byte)0, (byte)0, (byte)255,
		(byte)255, (byte)0, (byte)0, (byte)255,

		(byte)0, (byte)255, (byte)0, (byte)255,
		(byte)0, (byte)255, (byte)0, (byte)255,
		(byte)0, (byte)255, (byte)0, (byte)255,
		(byte)0, (byte)255, (byte)0, (byte)255,
		(byte)0, (byte)255, (byte)0, (byte)255,

		(byte)0, (byte)0, (byte)0, (byte)255,
		(byte)0, (byte)0, (byte)0, (byte)255,
		(byte)0, (byte)0, (byte)0, (byte)255,
		(byte)0, (byte)0, (byte)0, (byte)255,
		(byte)0, (byte)0, (byte)0, (byte)255,

		(byte)0, (byte)0, (byte)0, (byte)255,
		(byte)0, (byte)0, (byte)0, (byte)255,
		(byte)0, (byte)0, (byte)0, (byte)255,
		(byte)0, (byte)0, (byte)0, (byte)255,
		(byte)0, (byte)0, (byte)0, (byte)255,

		(byte)0, (byte)0, (byte)0, (byte)255,
		(byte)0, (byte)0, (byte)0, (byte)255,
		(byte)0, (byte)0, (byte)0, (byte)255,
		(byte)0, (byte)0, (byte)0, (byte)255,
		(byte)0, (byte)0, (byte)0, (byte)255,
	};
	int compress = 9;
	boolean alpha = true;
	PNGEncoder encoder = new PNGEncoder(5, 5, compress, alpha, data);

	// now let's write to the servlet output stream
	byte[] bytes = encoder.encode();
	resp.setContentLength(bytes.length);
	resp.setContentType("image/png");
	resp.getOutputStream().write(bytes, 0, bytes.length);
	resp.getOutputStream().flush();

So, as you can see, it is quite simple to invoke and pass data to. However, it still isn’t particularly easy to define your images (it is a bit hard to visualise from the above code what the output image would look like).

Memories…

Looking at a zoomed-in image, it reminded me of when, as a kid, I was using sprites to write animation for my Commodore 64. It struck me that I could do a similar thing here. What if I were to define a “sprite” and then just change the colours of each pixel at runtime? For example:

	PNGSprite sprite = new PNGSprite(5, 5,
		"RRRRR"+
		"GGGGG"+
		"XXXXX"+
		"XXXXX"+
		"XXXXX");

	sprite.setColour('R', (byte)255, (byte)0,   (byte)0);
	sprite.setColour('G', (byte)0,   (byte)255, (byte)0);
	sprite.setColour('X', (byte)0,   (byte)0,   (byte)0);

	byte[] bytes = sprite.encode();

Much simpler, no? All the PNGSprite.encode() method does is build an array of bytes like in the first example by iterating over the colours and substituting the correct RGB value.

Improving Performance

This technique, however, can be further improved. Users of the website typically tend to be looking at the same pages again and again, which means that the images do not change. Using the technique above, there is little opportunity for caching based on the passed colours. If we refactor slightly to make the sprite definition a constant and pass the colours into the encode() method, it gives us an opportunity to perform some caching. So, the new code would look like:

	private static final PNGSprite sprite = new PNGSprite(5, 5,
		"RRRRR"+
		"GGGGG"+
		"XXXXX"+
		"XXXXX"+
		"XXXXX");

	...

	byte[] bytes = sprite.encode(new PNGSprite.Pixel[] {
		new PNGSprite.Pixel('R', (byte)255, (byte)0,   (byte)0),
		new PNGSprite.Pixel('G', (byte)0,   (byte)255, (byte)0),
		new PNGSprite.Pixel('X', (byte)0,   (byte)0,   (byte)0),
	});

A Simple Cache

Not a huge change, but it now gives us an opportunity to perform some simple caching. Now, there are many, many caching algorithms but for the sake of the exercise let’s just create a simple one that caches them forever. Feel free to implement your own algorithm that better suits your performance/memory requirements.

	public class PNGSpriteCached extends PNGSprite
	{
		private HashMap _cache = new HashMap();
		public PNGSpriteCached(int width, int height, String pattern)
		{
			super(width, height, pattern);
		}

		/**
		 * Overloads the superclass' implementation to check for a
		 * cached local copy. If not found, then we ask the superclass
		 * to encode it and we store it for later use
		 */
		public byte[] encode(Pixel[] pixels) throws IOException
		{
			Iterator iterator = _cache.keySet().iterator();
			while (iterator.hasNext())
			{
				Pixel[] cachedPixels = (Pixel[])iterator.next();
				if (Arrays.equals(cachedPixels, pixels))
					return (byte[])_cache.get(cachedPixels);
			}
			byte[] bytes = super.encode(pixels);
			_cache.put(pixels, bytes);

			return bytes;
		}
	}

To take advantage of the caching, the only change we have to make is as follows:

	private static final PNGSprite sprite = new PNGSpriteCached(5, 5,
		"RRRRR"+
		"GGGGG"+
		"XXXXX"+
		"XXXXX"+
		"XXXXX");

Returning to Rounded Corners

So, getting back to our original requirement for generating rounded corners dynamically… let’s create a servlet that can create each of the four corners in whatever colour we want. For the following example, I am using 9×9 corners with a solid colour and a transparent outer section.

public class ImageServlet extends HttpServlet
{
	private static final PNGSprite tl = new PNGSpriteCached(9, 9,
			".......XX"+
			".....XXXX"+
			"....XXXXX"+
			"...XXXXXX"+
			"..XXXXXXX"+
			".XXXXXXXX"+
			".XXXXXXXX"+
			"XXXXXXXXX"+
			"XXXXXXXXX");
	private static final PNGSprite tr = new PNGSpriteCached(9, 9,
			"XX......."+
			"XXXX....."+
			"XXXXX...."+
			"XXXXXX..."+
			"XXXXXXX.."+
			"XXXXXXXX."+
			"XXXXXXXX."+
			"XXXXXXXXX"+
			"XXXXXXXXX");
	private static final PNGSprite bl = new PNGSpriteCached(9, 9,
			"XXXXXXXXX"+
			"XXXXXXXXX"+
			".XXXXXXXX"+
			".XXXXXXXX"+
			"..XXXXXXX"+
			"...XXXXXX"+
			"....XXXXX"+
			".....XXXX"+
			".......XX");
	private static final PNGSprite br = new PNGSpriteCached(9, 9,
			"XXXXXXXXX"+
			"XXXXXXXXX"+
			"XXXXXXXX."+
			"XXXXXXXX."+
			"XXXXXXX.."+
			"XXXXXX..."+
			"XXXXX...."+
			"XXXX....."+
			"XX.......");

	public void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException, ServletException
	{
		String id = req.getParameter("id");
		PNGSprite sprite = null;
		if ("tl".equals(id))
			sprite = tl;
		else if ("tr".equals(id))
			sprite = tr;
		else if ("bl".equals(id))
			sprite = bl;
		else if ("br".equals(id))
			sprite = br;

		if (sprite != null)
		{
			String col = req.getParameter("col");
			byte[] bytes = sprite.encode(new PNGSprite.Pixel[] {
			    new PNGSprite.Pixel('X', col),
			    new PNGSprite.Pixel('.', (byte)0, (byte)0, (byte)0, (byte)0)
			});

			resp.setContentLength(bytes.length);
			resp.setContentType("image/png");
			resp.getOutputStream().write(bytes, 0, bytes.length);
			resp.getOutputStream().flush();
		}
		else
		{
			resp.sendError(404);
		}
	}
}

Then, to actually invoke them, we would use the following HTML markup:

<img src="http://www.myserver.com/image?id=tl&col=00ff00ff"/>
<img src="http://www.myserver.com/image?id=tl&col=00ff00ff"/>
<img src="http://www.myserver.com/image?id=tl&col=00ff00ff"/>
<img src="http://www.myserver.com/image?id=tl&col=00ff00ff"/>

Thus creating the following images:

To download the source code for PNGEncoder.java, PNGSprite.java, and PNGSpriteCached.java, click here.

This describes the process for configuring Tomcat 5 on Ubuntu (or Debian) so that you can have multiple instances of Tomcat running. Typically, this would be useful when you have several domains (and/or applications) hosted on the one server and want to keep them running independantly of one another.

The general steps are based loosely on an article in LinuxJournal, however, I have added afew more explanations, corrected a couple of little inaccuracies and added new content to describe the Apache2 mechanism for loading modules and sites.

Pre-installed software

This guide assumes that you have already installed the following applications via apt-get:

• j2sdk1.4
• tomcat5
• apache2
• apache2-threaded-dev
• build-essentials
• a2enmod

Tomcat configuration

Two important environment variables for Tomcat are CATALINA_HOME and CATALINA_BASE. The first one is where the Tomcat files are actually installed (on Ubuntu Dapper Drake, using apt-get, this is /usr/share/tomcat5). The second one is where each running instance of Tomcat looks to find the configuration files and web applications. In the default installation, these variables are set to the same value. What we are going to do is create a directory for each of our webapps, and then start multiple instances of Tomcat with a different CATALINA_BASE for each one.

My suggested location (although I am open to feedback) is to create a new directory called /usr/share/tomcat5/instances that contains your applications. Looking at that containing directory, though, you see something like:

4 drwxr-xr-x   2 root root 4096 2006-08-15 08:02 bin
4 drwxr-xr-x   5 root root 4096 2006-03-19 16:27 common
0 lrwxrwxrwx   1 root root   21 2006-03-23 22:17 conf -> /var/lib/tomcat5/conf
4 drwxr-xr-x   2 root root 4096 2006-03-23 22:17 .debian
0 lrwxrwxrwx   1 root root   14 2006-03-23 22:17 doc -> ../doc/tomcat5
0 lrwxrwxrwx   1 root root   21 2006-03-23 22:17 logs -> /var/lib/tomcat5/logs
4 drwxr-xr-x   5 root root 4096 2006-03-23 22:17 server
0 lrwxrwxrwx   1 root root   23 2006-03-23 22:17 shared -> /var/lib/tomcat5/shared
0 lrwxrwxrwx   1 root root   21 2006-03-23 22:17 temp -> /var/lib/tomcat5/temp
0 lrwxrwxrwx   1 root root   24 2006-03-23 22:17 webapps -> /var/lib/tomcat5/webapps
0 lrwxrwxrwx   1 root root   21 2006-03-23 22:17 work -> /var/lib/tomcat5/work

You will notice that all the actual files are stored in /var/lib/tomcat5 with symbolic links across to them. To keep with this tradition, I used the following commands (all as root):

mkdir /var/lib/tomcat5/instances
ln -s /var/lib/tomcat5/instances /usr/share/tomcat5/instances
cd /usr/share/tomcat5/instances

So, now the base directories have been created, you need to do the initial setup for the Tomcat servers. Run the following commands for your webapp (where myapp is the name of your webapp):

mkdir -p myapp/conf myapp/logs myapp/webapps
cp ../conf/server.xml myapp/conf
cp ../conf/web.xml myapp/conf

Copy your application WAR file into the myapp/webapps directory, and we should be ready to go.

Starting your new instance

We can’t use the original /usr/share/tomcat5/bin/startup.sh to start each instance because it uses the default CATALINA_BASE, so what we do is create a new script file that can start and stop each instance, but pointing to a different CATALINA_BASE. Create a file called /usr/share/tomcat5/instances/myapp/myapp.sh that contains the following:

#!/bin/sh

RETVAL=$?
export JAVA_HOME=/usr/lib/j2se/1.4
export CATALINA_BASE="/usr/share/tomcat5/instances/myapp"
export CATALINA_HOME="/usr/share/tomcat5"
export CATALINA_PID=$CATALINA_BASE/logs/catalina.pid

case "$1" in
 start)
        if [ -f $CATALINA_HOME/bin/startup.sh ];
          then
            echo $"Starting Tomcat"
            exec $CATALINA_HOME/bin/startup.sh
        fi
        ;;
 stop)
        if [ -f $CATALINA_HOME/bin/shutdown.sh ];
          then
            echo $"Stopping Tomcat"
            exec $CATALINA_HOME/bin/shutdown.sh
        fi
        ;;
 *)
        echo $"Usage: $0 {start|stop}"
        exit 1
        ;;
esac
exit $RETVAL

Make sure the original Tomcat instance is stopped (by running sudo /etc/init.d/tomcat5 stop) and start your new instance by typing:

sudo chmod 755 ./myapp.sh
sudo ./myapp.sh start

Now test that Tomcat started up by pointing your browser to port 8180 of your machine with a valid myapp URL.

At this point, all we have really done is to make Tomcat start your application from a different directory. Useful, but not yet where we want to be. We realy want to be able to point the browser to port 80, instead of the non-typical port of 8180. So, we need to configure Apache to hand off to the new running instance using mod_jk.

mod_jk

mod_jk is the means by which Apache hands off incoming HTTP requests to the Tomcat instances. There are two flavours: mod_jk and mod_jk2. Despite what you would think, mod_jk is the more actively developed version and is actually much simpler to install and configure.

In the original version of Apache, you used to have to modify the httpd.conf file, however, with Apache2 things have changed a little. You can still edit /etc/apache2/httpd.conf if you like, but that isn’t the recommended way to configure Apache2. Instead, you will be creating configuration files in the following two directories:

• /etc/apache2/mods-available
• /etc/apache2/sites-available

Before you do that, however, you need to install mod_jk. Download the mod_jk source code, and run the following commands:

tar -xzvf jakarta-tomcat-connectors-1.2.14.1-src.tar.gz
cd jakarta-tomcat-connectors-1.2.14.1/jk/native
./configure --with-apxs=/usr/sbin/apxs2
make
sudo make install

The last command should install a file called mod_jk.so in /usr/lib/apache2/modules. You might want to just quickly check that it is there.

Now, you need to create a file called /etc/apache2/mods-available/jk.load that contains:

LoadModule jk_module /usr/lib/apache2/modules/mod_jk.so

Next, create a file called /etc/apache2/mods-available/jk.conf that contains:

<IfModule mod_jk.c>
  JkWorkersFile       "/etc/apache2/workers.properties"
  JkLogFile           "/var/log/apache2/mod_jk.log"
  JkLogLevel          info
  JkLogStampFormat    "[%a %b %d %H:%M:%S %Y] "
  JkOptions           +ForwardKeySize +ForwardURICompat -ForwardDirectories
  JkRequestLogFormat  "%w %V %T"
</IfModule>

Now, from the command prompt, type the following commands to enable it and become effective. The a2enmod command enables a specific module by creating a symbolic link in /etc/apache2/mods-enabled that points to the equivalent file in /etc/apache2/mods-available directory.

sudo a2enmod jk
sudo /etc/init.d/apache2 force-reload

Nice work. Now you have enabled mod_jk. Now we have to configure a virtual host in Apache to point to our Tomcat instance. You do this by creating a file called /etc/apache2/sites-available/yourdomain.com and adding the following content:

<VirtualHost yourdomain:80>
        ServerAdmin admin@yourdomain.com
        ServerName  yourdomain.com
        ServerAlias www.yourdomain.com

        JkMount /* myapp
</VirtualHost>

This defines a virtual domain that has a Tomcat application called myapp. In fact, the myapp identifier is not actually the application name, but actually references an entry in the workers.properties file (see below). However, while not strictly necessary, if you keep this naming convention it makes it nice and easy to read the configurations when your mod_jk identifiers are the same as your webapp names. The JkMount /* myapp directive instructs Apache to send all urls to Tomcat (via mod_jk). You can, if you choose, a different pattern that more accurately reflects which requests you want Tomcat to handle (for example, JkMount /*.do myapp).

You need to make this new site available for use, so type the following command:

sudo a2ensite yourdomain.com
sudo /etc/init.d/apache2 force-reload

And lastly, we need to tell mod_jk what port Tomcat will be listening on by creating the configuration file that we referenced in /etc/apache2/mods-available/jk.conf. So, create a new file called /etc/apache2/workers.properties that contains:

worker.list=myapp

# Set properties for myapp
worker.myapp.type=ajp13
worker.myapp.host=localhost
worker.myapp.port=8009

The worker.list directive says which of the configurations is available for use. For now, only myapp is available because we have only got one application. This tutorial has Tomcat and Apache on the same machine, so we use localhost as the host. The port that mod_jk will send connections to is 8009, which is the default Tomcat AJP13 listening port. When we add second, and subsequent, applications we will use different port numbers.

Stop and restart Apache by running the following command:

/etc/init.d/apache2 restart

Now, point your browser to your machine, but on port 80 this time. If all has gone well, you should seamlessly get passed through Apache into Tomcat via AJP.

The last thing to do is make Tomcat only accept incoming connections via the AJP connector, instead of allowing connections directly to port 8180 (the HTTP connector). This can be done by editing the myapp/conf/server.xml to comment out the HTTP connector.

<!-- Connector className="org.apache.coyote.tomcat5.CoyoteConnector"
               port="8180" minProcessors="5" maxProcessors="75"
               enableLookups="true" acceptCount="10" debug="0"
               connectionTimeout="20000" useURIValidationHack="false" / -->

Adding second and subsequent webapps

Adding additional webapps is reasonably straightforward. One thing to decide before proceeding is what port numbers to use for your new webapp(s). The default server.xml will have the shutdown port being 8005 and the AJP connector port being 8009. Now, we already know that our first webapp (myapp, in this example) is using those ports, so we need to pick new port numbers. You can pick any port numbers you like, but the convention seems to be 8105/8109 for the second webapp, 8205/8209 for the third, and so on. The required steps are outline below:

1. Run the following commands:
   

   mkdir -p app2/conf app2/logs app2/webapps
   cp ../conf/server.xml app2/conf
   cp ../conf/web.xml app2/conf
   

2. Edit the app2/conf/server.xml, changing these items:
   • Change the port attribute of the <Server> tag from 8005 to 8105.
   • Change the port attribute of the AJP <Connector> tag from 8009 to 8109.
   • Optionally, comment out the HTTP <Connector> tag. If you don’t comment it out (and you didn’t comment it out in myapp/conf/server.xml) you will need to change the value from 8180 to 8181 (or some other port) so that the HTTP connectors of your two webapps aren’t listening on the same port.
3. Edit the /etc/apache2/workers.properties to add new lines that look like:
   

   worker.list=myapp,app2
   
   # Set properties for myapp
   worker.myapp.type=ajp13
   worker.myapp.host=localhost
   worker.myapp.port=8009
   
   # Set properties for app2
   worker.app2.type=ajp13
   worker.app2.host=localhost
   worker.app2.port=8109
   

4. Create a file called /etc/apache2/sites-available/anotherdomain.com and adding the following content:
   

   <VirtualHost anotherdomain:80>
           ServerAdmin admin@anotherdomain.com
           ServerName  anotherdomain.com
           ServerAlias www.anotherdomain.com
   
           JkMount /* app2
   </VirtualHost>
   

5. Enable your new site by running the following commands:
   

   sudo a2ensite anotherdomain.com
   sudo /etc/init.d/apache force-reload
   

6. Copy the myapp/myapp.sh script as app2/app2.sh directory, and modify the line with CATALINA_BASE to point to the app2 directory instead of the myapp directory.
7. Copy your application WAR file into the app2/webapps directory
8. Restart Apache by running /etc/init.d/apache2 restart
9. Start your application by running app2.sh start

Starting automatically

Now, having installed your webapp successfully, you may want to get it to start automatically upon a system restart. The conventional way to do this is to run the following commands:

sudo ln -s /usr/share/tomcat5/instances/myapp/myapp.sh /etc/init.d/myapp.sh
sudo update-rc.d /etc/init.d/myapp.sh defaults 70

Repeat these commands for whichever Tomcat servers you want automatically restarted.

Feedback

If you spot any typos or mistakes, please let me know and I will correct ASAP. Thanks a lot.