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

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)

Installing Java

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)

jdk-6u6-linux-i586.bin

(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

./jdk-6u6-linux-i586.bin

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)

emacs /etc/profile

(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

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)

(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)

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 :)More later!

(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)Conventions

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 tabInstalling Tomcat 5.x and getting it to communicate with IIS 6.x

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_HOMEYou 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.

;c:\java\jdk version\bin

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:8080should 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\Connectorscopy 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.

e.g. 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

extension_uri=/jakarta/isapi_redirect-connector version.dll

# Full path to the log file for the ISAPI Redirectorlog_file=c:\tomcat_tomcat version\logs\isapi_redirect.log

# Log level (debug, info, warn, error or trace)log_level=warn

# Full path to the workers.properties fileworker_file=c:\tomcat_tomcat version\conf\workers.properties

# Full path to the uriworkermap.properties fileworker_mount_file=c:\tomcat_tomcat version\conf\uriworkermap.properties

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 :)

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)

Create a uriworkermap.properties file in the same c:\Tomcat_tomcat version\conf folder containing the following/|*=worker1

(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.

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.

[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 Priorityunknown 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.

Back in those days, I was trying to write for all browsers – not that it was too hard a thing to do; we had hardly the fully fledged, feature-filled things we have today. Still, I remember fondly writing html code to display in Mosaic, in lynx, in NCSA Navigator and then, Netscape Navigator 2 (then 3 which introduced FRAMES :) ) and so on. Very quickly, Netscape became my browser of choice; I remember writing simple shopping cart style demo-sites using JavaScript; testing in Netscape 2 and 3 and then adding “flash look and feel” things to it; designing animated gifs using a mixture of paintshop pro and microsoft paint (I know) with a couple of bespoke tools. I learned a lot about “bad design practices” (mostly through engaging in them myself and wondering why nobody could access my sites :) ) and so on; then moving to Netscape 6 before dabbling with Mozilla for a long while, eventually settling on firefox…

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)

It’s interesting seeing things like David Meyer’s blog “Communication Breakdown” on ZD Net, “Facebook email privacy has a hole” (Jan 12th 2008) which talk about a “discovered” bug, flaw, or issue in the social networking tool of today. In this instance, a flaw in the mobile version of the service which exposed contacts’ email addresses whether they wanted them exposed or not. Fortunately, it sounds like the flaw has been rectified not long after being spotted, but it does send a warning to developers of social software; especially in this age where the web is no longer only accessed via the desktop; with a multitude of devices connecting, each with their own set of unique applications – we have to ensure that privacy is maintained; that we don’t poke holes in an otherwise strong and secure application.

Reading “Google/OpenSocial’s director of engineering David Glazer unplugged: ‘Shindig is live’” on ZDnet today; interesting that our Innovations specialist mentioned this to me a couple of days ago. (Although his take on the OpenSocial network was that it would probably be utilized by minority groups in the social networking scheme of thing (so no uptake by myspace or facebook?) However, this item on ZDnet talks about the social networking site, Bebo; apparently the most popular social networking site in the UK , Ireland and New Zealand. The interesting aspect about Bebo is that it is API-compatible with Facebook; meaning things written for Facebook will work on Bebo without any need for recoding.

Which David Berlind, the article’s author, points to pushing the case for the interoperability promoted by the OpenSocial standard (which, incidentally Bebo will be also supporting next year)

I need to find some time to follow some of the related links and read up a bit more; this looks interesting but we’ll see what happens.