Posts Tagged ‘IIS 6’
(with apologies to Rodgers and Hammerstein for appropriating the song “Happy talk” (from South Pacific) for my subject title :) )
Over the past couple of weeks I’ve been trying to get an installation of Tomcat talking with IIS 6. Something which I’ve found all sorts of documentation about, most of it misleading – or not appropriate to the versions I was attempting to get to communicate.
It’s the joys of being a developer with responsibility for the various servers, someone buys an application and comes to me and says “make it work” – I read through the supplier provided instructions and announce, “if it is as simple as these instructions make it look… well, it’ll only take 5 minutes to do”
Of course, it’s never as easy as the instructions make it look.
And it doesn’t help when the supply eventually gets back to us and tells us “actually, the instructions we gave you are completely wrong and hideously out of date”
Never mind though – I got it all working (and in case I ever need to do it again, here’s how)
in italics – text in italics will indicate a comment or note following a command or statement. e.g. doing this makes it work
in bold - text in bold will indicate information which is installation specific. e.g. version numbers
underlined – underlined text will be used to highlight a choice e.g. select the security tab
Installing Tomcat 5.x and getting it to communicate with IIS 6.x
You will need;
- A current Java JDK (note – JDK – not JRE) (in this example it is 184.108.40.206)
Download from http://java.sun.com/javase/downloads/index.jsp
- The current, stable, version of Tomcat 5 (in this example it is 5.5.26 )
Download from http://tomcat.apache.org/download-55.cgi
- The currrent, stable, isapi filter (Tomcat Connectors) (in this example it is 1.2.26 (December 2007))
Download from http://tomcat.apache.org/download-connectors.cgi
When it comes to performing installations, there is a mixture of opinions as to where to place the files. By default, the applications want to install into c:\program files\…. etc. using folders with spaces. During my tests I did have issues with paths (and including paths with spaces within quotes didn’t really make too much difference); some of the (online) notes I found made use of installation directories without spaces – and when I followed suit I experienced much less in the way of issues – so it is my preferred way of doing things, if only because I know I can make things work that way :)
1 Install Java
Simply run the Java installer; select the directory “c:\java\jdk version” for the root; if you’re installing the netbeans component (and I think they all come with the netbeans component) then I suggest installing it under “c:\java\netbeans version”
Set the environment variables for JAVA_HOME. In windows XP/2003 this can be done by right clicking on the “my computer” icon on the desktop, selecting the advanced tab, then clicking the Environment Variables button. We want to add the variable as a System Variable so we would click the New button under the System variables section.
You add the Variable name as JAVA_HOME
You add the Variable value as c:\java\jdk version (or wherever it was you decided to install java)
You can also edit the PATH environment variable to point to the JAVA applications. (Highlight PATH on the list and select Edit. Assuming there isn’t already anything pointing to a “java” location, add the following to the end of the line.
This will ensure you’re using the correct version of JAVA. (if there was a previous entry, this should be removed and replaced by this one)
2 Install Tomcat
Run the tomcat installer process; make sure the installer points to the version of JAVA we’ve just installed (the environment variable for JAVA_HOME that we set should ensure this, but it’s always good to make sure :) ). Install Tomcat to the directory c:\Tomcat_tomcat version number (without spaces – e.g. c:\Tomcat_5.5.26)
When you’re prompted for an administration user you can accept the standard “admin” (although I tend to change it to something less standard) and enter a password – make a note of these details as you’ll need them to access the management console.
Add the following environment variables; TOMCAT_HOME and CATALINA_HOME
(using the same method as used for JAVA_HOME add an entry in the system variables for TOMCAT_HOME and CATALINA_HOME – both should have their values set to c:\Tomcat_tomcat version number
You should have tomcat running, by default, on port 8080. You should have the “Apache Tomcat” controller application appearing in the windows system tray. If every thing is working as it should, this should have a little green arrow in it identifying that Tomcat is running. If it doesn’t, there could be a conflict. A quick (and easy) test is to start up a web browser (I use, and recommend, firefox – but each to their own) and point it at our Tomcat Server. If it’s on the same machine, then http://localhost:8080 should pull up the “welcome to tomcat” webpage
. If it pulls anything else up then this could be due to local dns issues (check you don’t have localhost aliased to something odd in the file c:\windows\system32\drivers\etc\hosts ) or other services running on the server.
Assuming Tomcat is working, we can now look at making it talk with IIS.
3 Install the Tomcat Connector
Part 1; Tomcat side Installation
While it doesn’t particularly matter where you install the connectors, historically (and logically) it is best to install them within the same folders that Tomcat has been installed in.
Create a directory c:\Tomcat_tomcat version number\Connectors
copy into this folder the isapi filter (also referred to as a jkConnector) you acquired earlier. ( isapi_redirect-1.2.26.dll )
You then need to create a configuration for the connector. You may often find references to doing this via meddling with the windows registry keys. While this may work (I had no joy with this), it is most definitely not a way I’d recommend anyone configure anything. The preferred method is to create a configuration file in the same folder as the Tomcat Connector. This will have exactly the same name as the dll file, but with “properties” as it’s extension instead of dll.
using the Connector isapi_redirect-1.2.26.dll means you’ll need to create a file called isapi_redirect-1.2.26.properties
Using a “property” file rather than manipulating registry keys means that multiple filters can be installed and used (which has a benefit when you need to upgrade, you can test out the configuration without damaging the existing service etc. )
Into the properties file (edit in notepad) add the following settings
# Configuration file for the Jakarta ISAPI Redirector
# The path to the ISAPI Redirector Extension, relative to the website
# This must be in a virtual directory with execute privileges
# Full path to the log file for the ISAPI Redirector
# Log level (debug, info, warn, error or trace)
# Full path to the workers.properties file
# Full path to the uriworkermap.properties file
I’ll try and explain what these all do.
- extension_uri – this points to the location where the connector will be loaded into IIS
- log_file – the location of the log file; by default I try and put it with the other Tomcat logs to make it easy to access and compare requests.
- log_level – when you’re first setting this up, you may want to set it to debug to get full and detailed logs generated; just make sure you drop it back to warn when you go to a production environment or you’ll find logs spiraling out of control :)
- worker_file – the path to the workers.properties file; this is essentially where we set up all the attributes (workers?) for this connector (in my mind it would make sense to have an option to amalgamate this into the current properties file – but never mind – there’s usually good reasons for multiple configure files (and I don’t just mean to separate the men from the boys :) )
- worker_mount_file – the path to the uriworkermap.properties file; this is the file where you associate applications to specific workers. If your webapp doesn’t have an entry in here you’ll not be able to access it through IIS
As you’ve created links to property files, you’ll need to make sure they exist. By default they won’t – so don’t expect anything to work just yet :)
Create the workers.properties file in c:\Tomcat_tomcat version\conf containing the following.
# Define 1 real worker using ajp13
# Set properties for worker1 (ajp13)
This is the most basic configuration for the worker.properties; in case it isn’t obvious what is happening here I’ll try and explain. You’re saying you have a single worker (you can have multiple workers, and then do things like load balance etc. with them). It is using the ajp13 protocol (there were previous protocols, but this is the current preferred standard – more details (technical) http://tomcat.apache.org/connectors-doc-archive/jk2/common/AJPv13.html) and is running on the local host computer on port 8009. (Which means IIS will try and communicate to Tomcat through this port)
Much more information about the workers.properties can be found at the Apache/Jakarta site http://tomcat.apache.org/connectors-doc/reference/workers.html
Create a uriworkermap.properties file in the same c:\Tomcat_tomcat version\conf folder containing the following
(yes, just a single line!!!)
What this does is say “any content requested should be given to worker1″. Note that the worker names should all be consistent otherwise nobody knows who they’re talking to.
Obviously, once we have everything working we will want to change this; we will most likely not want to pass all content to the tomcat server, rather limiting things to the specific webapps we’ve constructed and want to deploy to the outside world.
(will pass the specific “my_web_app” to whichever worker you’ve decided to associate it with)
much more information can be found at the Apache/Jakarta site http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html
That should be all you need to do for Tomcat to reveal itself (ready for IIS); you can restart tomcat if you like and attempt to telnet to port 8009 (there won’t be anything interesting to see – you should get a connection which quickly closes – if I can work out (or find) a way to perform a useful test, I’ll add it later)
Part 2; IIS side installation
As with all IIS sites, you need a root directory; security/backup concerns will often have you creating a folder away from the O/S drive – e.g. D:\Tomcat-IIS-site . Once this is created you can open the IIS Manager [found via: Start Menu, Administrator Tools, Internet Information Services Manager (IIS)]
Expand the Tree in the left hand window so you have the following exposed.
Internet Information Services
[-]—-This server name (e.g. IIS-server-01) (local computer)
[+] Application Pools
[ -] Web Sites
[+] Default Web Site
[+] Web Service Extensions
[Right click] on Default Web Site and select stop ; the default site will run on port 80 which is where we’ll want our site running. Obviously if your server is already providing a number of services you’ll not want to stop the default site as this would be a bit disastrous for your clients!!
Now [Right Click] on Web Sites and chose New, Web site ; call it something obvious (e.g. IIS/Tomcat site ) point the directory root to the root directory you created earlier (e.g. D:\Tomcat-IIS_site ) – assuming that this will be the only service running on this server (or you have a specific domain name set up for this site) you can chose to run on all unassigned IP Addresses and port 80. If you have other things running on this service, or maybe want to perform a dummy “test” installation, you may chose to install this site on a different port that’s available.
Now [Right Click] on the new site, and select [New] , [virtual directory] ; give it a name of jakarta (remember – you gave it this name back when you created the properties config file for the tomcat connector?) and point the directory to the one containing the Tomcat connector. ( c:\tomcat_tomcat version\connectors ); this directory will need to have execute access
Next you need to set up the connector to act as a filter for IIS. First [left click] on Web Service Extensions – on the right hand pane you’ll have a list of the currently installed isapi filters (allowed and disallowed). On the left of this pane there will be a link to add a new Web Service Extension select this and type jakarta as the extension name, then select [Add] and browse to the c:\Tomcat_tomcat version\Connectors folder and select the isapi_redirect-version number.dll ; tick the set extension to allowed checkbox and okay everything. You should now have the jakarta filter listed as allowed in the extension list.
Now [right click] on your website, select properties and chose the ISAPI Filters tab; select [add] and enter a filter name of jakarta (as per the connector properties file created earlier) and point the executable to the dll in the c:\tomcat_tomcat version number\Connectors directory
In the pane you should now see something along the lines of
Status Filter name Priority
unknown jakarta unknown
if you okay everything, [right click] on the web site name, select stop followed by start (once it has stopped) and then go back to the ISAPI Filters you should see that the Status will be replaced with an arrow – hopefully a green arrow pointing up. If you have a red arrow pointing down then something has gone horribly wrong; retrace your steps. It may be an idea to confirm that the SYSTEM and anonymous accounts that IIS uses have read access to the folder and files in the Tomcat Connectors directory.
If you have no arrow – don’t worry; IIS is just being a bit slow. Test the site again using your browser of choice, only this time without specifying a port. i.e. http://localhost/
If you were using the “pass everything to tomcat” rules in the uriworkermap.properties file then you should be presented with the “welcome to tomcat” page – the same as you’d receive if you pointed your browser to http://localhost:8080/ .Assuming this works, your tomcat/IIS installation is a success. Well done. Have a cup of tea and a slice of cake (this is optional)
Since the installation I’ve been having issues with CPU utilization on this set-up. I will follow up this with a post regarding tweaks that have been made (hopefully successfully) to improve performance. I might post an additional note regarding testing and troubleshooting. But that’s for another day. Right now I’m going to look at getting IIS 6 and Tomcat 6 talking. My track record so far is II6 and Tomcat 4 – failed to talk; IIS 6 and Tomcat 5 – talk happily; IIS6 and Tomcat 6 – failed to talk (so far; although someone else did the initial installs)