Well, that was lunch… back to the install.
After all that work, we should have a working version of tomcat. However, we don’t have any users set up – so how do we manage our applications (etc) ? Well, first things first, let’s create a role in the
[tomcat root]/conf/tomcat-users.xml file.
it should look something like this
<?xml version=’1.0′ encoding=’utf-8′?>
<user username=”[pick a name]” password=”[pick a password]” roles=”manager” />
once you have made the changes, you’ll need to restart tomcat
(wait a few moments – you can type ps guax|grep java to see if the process has stopped before running)
to start the service up again.
You can check in the /[tomcat root]/logs/catalina.out file to see if there are any errors generated .
Well, here we are again :) Installations! This time I’m installing Tomcat (not sure which version yet – possibly 6.x ) on a linux box. Of course, there’s a bit of head scratching and finding out exactly what we need to do prior to install.
So, we have a vanilla system. It has apache running but has never seen hide nor hair of anything like java. So first I have to download a jdk – sounds simple ? Well, it should be – but like many people I tend to get a bit confused when it comes to navigating Sun’s java site. So many varieties of jdk, sdk, jre with or without beans and whatever new “technological methods” Sun have come up with. Occasionally conflicting documentation (search for jdk linux – you get instructions telling you to install obsolete software … or is it obsolete ? I’ve no idea)
As I’m not sure I have access to compilers and the like (a legacy policy of never putting any sort of development malarkey on a front-facing server) I’m going to have to pick a binary install; which should work fine without any issues… I hope!
(fortunately, if there are any issues – this is a soon-to-be-decommissioned box that is just sitting around spinning it’s wheels, so to speak; so it’s not going to take down any “mission critical” applications … at least… it shouldn’t do :) )
In this instance, I’ve decided upon the Linux binary distribution of the Java SE Development Kit 6 (update 6) (I’d give a link to the page on java.sun.com but that looks to be generated via session variables on a by-user basis)
(from the page http://java.sun.com/j2se/1.5.0/install_jdk150-nb40_linux.html we are told to set the permissions on the file so we can execute it; they say chmod 755 jdk*.bin although my preferred method is chmod u+x jdk*.bin (but that’s just me … oh, and I’m just being lazy – you can type the whole jdk filename in if you want (or if you have lots of jdk’s in the folder and don’t want them all to be executable :) )))
let’s run the executable
Good grief ! That’s a long user agreement… I really should read it one of these days, I heard rumours of them smuggling clauses allowing them to take your first born son … but… life’s too short :) and generally they could be summarized into a simple statement
“you agree to not do anything naughty – like stealing things , we’ll find out and catch you you know.”
to which, we have to say “yes” (surely we should be able to say “no, we don’t agree” and still use the software? Are these things really binding? I don’t know… anyway… I’m digressing )
of course, once it gets to the end “Java(TM) SE Development Kit 6 successfully installed”
So what have I got ?
in the directory I ran the jdk in, there is now a folder “jdk1.6.0_06” ; to make upgrades (hopefully) easier, I’ll make a symbolic link to this directory
ln -s jdk1.6.0_06 java
I’ll now set up some environment variables (so we know where to find things)
(or feel free to use vi or whichever text editor you prefer)
Assuming you’ve not done anything to tweak the default profile, there will be a line in the file that says something like
export PATH DISPLAY LESS TERM PS1 PS2
before this line I’ll add the following
JAVA_HOME=/[path to java install eg. /usr/local/java]
and then on the end of this line I’ll add JAVA_HOME and CLASSPATH
export PATH DISPLAY LESS TERM PS1 PS2 JAVA_HOME CLASSPATH
that done, I can type . /etc/profile which’ll re-set the environment variables (which can be proven by typing java -version ); which in turn means we can now run java. Now to install tomcat. Let’s try tomcat 6…
Installing Tomcat 6
First to download our copy of tomcat. http://tomcat.apache.org/download-60.cgi (Question: Why aren’t there any “linux” versions listed ? Answer: Because it’s java! The same package as is installed on windows will work on Macs, unix boxes and all sorts of places – probably even your hand-held device (assuming it has space for it!)
We’ll download the tar.gz version (tar being a unix standard “tape archive” (remember unix principles 101?) and gz being the gzip compression format (as tar archives are uncompressed by default – remember? Were you listening ? :) )) at the moment, the latest archive is http://www.smudge-it.co.uk/pub/apache/tomcat/tomcat-6/v6.0.16/bin/apache-tomcat-6.0.16.tar.gz (note that this is linking to one of the many mirror sites used for distribution of the apache/jakarta projects)
change directory to your installation folder – e.g. cd /usr/local
decompress the archive – gunzip apache-tomcat-6.0.16.tar.gz
untar the archive – tar -xmvf apache-tomcat-6.0.16.tar
(alternatively, you can miss out the decompressing stage and instead use tar -xmzvf (the z is for decompress gzip format)
we’ll make another symbolic link now, to make it (hopefully) easier to upgrade
ln -s apache-tomcat-6.0.16 tomcat
in the tomcat directory there will be a folder called “RUNNING.txt” – the following notes are derived from that…
First I’ll edit the /etc/profile file again and add in a new environment variable for “CATALINA_HOME” (this will point to the installation folder) and ensure that the variable gets exported – similar to the JAVA_HOME
in theory, we should now be able to start up tomcat and see it running on port 8080 – cd $CATALINA_HOME/bin and type ./startup.sh
When I tried this just, it complained about being unable to find a file … “setclasspath.sh” – which is strange as it is right there… Let’s try and troubleshoot a little bit…
(A quick search online provides an answer to this – on the tomcat wiki )
We have to edit the catalina.sh and setclasspath.sh files and add the following lines (to the beginning)
BASEDIR=/[path to your tomcat install]
CATALINA_HOME=[/path to your tomcat install]
we can then try again – cd /path to tomcat/bin
if everything works okay, we should then be able to type
ps guax | grep java
which’ll show the process (note, versions of ps differ from system to system; so if you get an error, you can always try ps -guax or some other combination – remember the system manual is your friend :) man ps )
we can now try and display the site – in a web browser, point it to the server on port 8080 – if everything has worked (as it has in my case) you’ll get the default tomcat server page/documentation/examples.
And as everything has worked so far – I think it’s a good time to take lunch :)
(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)
From following Brian Kelly’s UK Web Focus blog post “The demise of Netscape Navigator” (which in turn references the Guardian’s “In praise of netscape” (Sat 1st March 08)) I was first informed of the passing of one of the major forces in the web today; the “Netscape Navigator” browser… When I first came to the web as an aspiring young … well, if I’m totally honest, as a degree student looking for a way to waste time that didn’t involve alcohol, drugs or … really anything that involved me spending too much money… well, it was quick to get lost in it.
I probably would have moved towards the web in my own way, in my own time. But it was Netscape that facilitated that. That made it fun. Even if they did throw the cat among the pigeons with their flagrant abuse of (HTML) standards and so on; it was competition. It raised the game and brought innovation to the web. Like the Guardian’s article says, Netscape paved the way for everything we have today. Facebook, Myspace, Amazon et al. Were it not for Netscape bringing the web to the masses; without that vision and drive… we wouldn’t be where we are today.
So today, my browser of choice is Firefox; the child-spawn that has come of age, birthed from the ashes of Netscape/Mozilla. My art package of choice is the Serif PaintPlus (6) software and my HTML/code editor of choice… is 50/50 Macromedia Dreamweaver (4) / Notepad … some things never really change…
(It’s kind of odd feeling nostalgic for a piece of software… I wonder if people get the same feeling for Lotus 1-2-3 or the various DOS spreadsheets that once existed… sighs)