The Author – Bart Busschots
Creative Commons
Unless otherwise stated, the content on this site is licensed under Creative Commons Attribution, Noncommercial, No Derivative Works 3.0 License
May
22
Installing Apache Tomcat 5.5 on Linux
Filed Under Computers & Tech, System Administration on May 22, 2006 | 33 Comments
I’ve previously done a guide on the right way of installing Tomcat 5.0 on the Mac but things are a little different on Linux so I figured I’d do another guide. This one is a little less advanced because it only covers running Tomcat as root and not as a non-root user. Depending on how busy I am in the next while I may or may not do a follow-up article on the additional steps needed to run Tomcat as a non-root user. I have tested this procedure on RHEL ES 4 with Tomcat 5.5.17 and the Sun JDK version 1.5.0_6 but it should be the same on all Linux distros and for all 5.X Tomcat versions, the only thing that is likely to change is the location of $JAVA_HOME. Correction, the startup script included is for Redhat based distros only (RHEL, Fedora, CentOS etc).
Jan
26
Guide for Installing Tomcat 5.0 on OS X 10.4 Tiger
Filed Under Computers & Tech, Software Development on January 26, 2006 | 24 Comments
This is a step-by-step guide to installing Tomcat 5.0.x onto OS X 1.4.x. Note that this is the Tomcat branch for the 1.4 JDK and not for the 1.5 JDK. I know the latest versions of OS X now have Java 5 as part of the OS but my work is not yet ready to migrate to Java 5 so I’m staying with Tomcat 5.0 for now. The chances are that these instructions with only tiny and obvious alterations will work for Tomcat 5.5 with Java 5 but I’m not making any promises. Read more
Oct
8
Is there any need for the Applet anymore?
Filed Under Software Development, Computers & Tech on October 8, 2005 | Leave a Comment
Now that the worst of the ‘browser wars’ finally seems to be behind us and now that JavaScript can easily communicate with servers to get data without page re-freshes via AJAX one has to wonder if there are any real uses left for applets. My conclusions would be that yes there are still some uses for applets on the web but they are few and far between. Anyone who uses an applet in this day and age should have a bloody good reason to do so because your browser should not have to load a JVM just to view a web page unless that JVM is providing something spectacular that actually adds something to your page and that cannot be done with the core web technologies (XHTML, CSS, JS, AJAX).
Oct
4
The CORRECT way to install Sun Java on Debian/Ubuntu
Filed Under Computers & Tech, System Administration on October 4, 2005 | Leave a Comment
This little guide is just a greatly padded out version of instructions I got from Misha but since we have quite a few Ubuntu users and quite a few Java programmers in MiNDS> this should come in quite useful.
Basically this is the Debian way of installing the Sun JSDK so that it can be managed with dpkg and hence easily upgraded or removed at a later date.
Firstly, since Ubuntu IS a distribution of Debian really I will just refer to Debian in these instructions but the instructions also apply to Ubuntu and in fact it was on Ubuntu that I tested this. Also, these instructions assume that you are logged in as a user who has access to root via sudo.
The way this will work is that we will use a Debian package called java-package to turn the binary Linux installer we get from Sun (or IBM and others too) into a proper Debian package (.deb) and then we will use Debian’s package manager (dpkg) to install that Debian package.
The first step in the process is to install the java-package program that will allow us to create the .deb file. To do this simply type:
sudo apt-get install java-package
If you are asked for a password it is for sudo and you should enter your own login password.
The next step is to go to java.sun.com and download the Linux binary installer for the JSDK that you want to install. DO NOT DOWNLOAD THE LINUX RPM FILE!
The next step is to use java-package to turn this binary file into a Debian package, to do this move into the folder where you downloaded the binary file from java.sun.com.
NOTE, if you are doing this in the college on your machine for your 4th year project you will have to copy the binary file to /tmp and work from there because local root does not have access to your NFS mounted home directory.
For this step you will need fakeroot, if you don’t have it installed install it with apt-get like so:
sudo apt-get install fakeroot
Once you have fakeroot installed and you are in the right directory start the packaging with the command (replacing file_from_sun.bin with the actual name of the file you got from Sun):
fakeroot make-jpkg file_from_sun.bin
This will now appear to run the Sun installer but rather than installing it into your system it is extracting it to a temporary fake root file system and then creating the .deb file from the files in that fake file system. During this stage you will be asked to agree to the Java license agreement.
When the above command completes (will take a few minutes) a .deb file will have been created in your current folder. This is the file that we will now install with dpkg as follows (replacing name_of_deb_file.deb with the actual name of the .deb file created):
sudo dpkg -i name_of_deb_file.deb
And hey presto you are finished, when ever you want to get rid of that JDK all you have to do is (replacing name_of_deb_file_without_The_extension with the name of the generated .deb file but with the .deb extension left out, e.g. sun-j2sdk1.5):
dpkg --purge name_of_deb_file_without_The_extension
You can then install a new JSDK in the same was as described above or just leave your system Java free (heaven knows why you’d do something mad like that!)
Sep
3
Shelling out in Java re-visited
Filed Under 42 (Life the Universe & Everything) on September 3, 2005 | 2 Comments
Following on from my previous post on shelling out in Java.
When shelling out in Java there are only two models you get by default, you can either set the process off and carry on your thread of execution in parallel, or you can halt your thread of execution until the thread you spawned finishes. The questions is, what if you want something in between, what if you want to wait for a given length of time and then simply assume that something has gone horribly wrong and kill the child process and then move on?
Well, I have what I consider to be a good solution!
The following is a Java function that allows you to specify just
about everything you could ever need when shelling out. It has made my
life a lot easier so hopefully it will be of some use to other people
too!
/** The exit code that indicuated success. */
public final static int SUCCESS = 0;
/**
* A static method to execute a given command on the shell and return the exit
* code.
*
* @param cmd The command to execute.
* @param waitForSecs How many seconds to wait for the spawned thread to
* terminate. A value of zero indicated not to wait at all but to let the
* new process carry on in the background. A negative value indicates
* that this function should wait indefinitely for the spawned process to
* finish and any positive value will be interpreted as the number of
* seconds to wait for the process to terminate before killing it.
* @param workingDir The working directory for Java to use. If a blank
* string or null is passed no working directory is set.
* @param env The environment variables to shell out with. If an
* empty array or null is passed no environment variables will be sent
* are sent.
* @return Whether or not the spawned process exited without
* errors. If we are not waiting for the proccess to end it is impossible
* to know this so false will always be returned.
* @exception Exception If any exception is thrown in the process of
* executing the command it is caught and encapsulated in a Exception
* and then re-thrown.
*/
public static boolean executeCommand(String cmd, String[] env, String workingDir, int waitForSecs) throws Exception {
try {
String[] theEnv = env;
if(theEnv == null) {
theEnv = new String[0];
}
Process proc = null;
if(workingDir != null && !workingDir.equals("")) {
proc = Runtime.getRuntime().exec(cmd, theEnv, new File(workingDir));
} else {
proc = Runtime.getRuntime().exec(cmd, theEnv);
}
//if we are not waiting, return
if(waitForSecs == 0) {
return false;
}
//if we are waiting indefinitely, do so
if(waitForSecs < 0) {
return SUCCESS == proc.waitFor();
}
//if we are waiting for a set amound of seconds do so
int waited = 0;
do {
Thread.sleep(1000);
try {
boolean ans = SUCCESS == proc.exitValue();
return ans;
} catch(IllegalThreadStateException e) {
//the thread has not finished yet
waited++;
if(waited >= waitForSecs) {
//we have been here too long, kill the process and return false
proc.destroy();
return false;
}
}
}while (true);
} catch(Exception e) {
throw new Exception("An exception occouted while shelling out for the command " + cmd, e);
}
}
Sep
2
String.replaceAll(String, String) wowes
Filed Under Software Development on September 2, 2005 | 9 Comments
When you are dealing with databases one of the most common things you have to do is to escape out all single quotes in text being entered into the DB to stop PostgreSQL/MySQL/*SQL having a cow and to prevent injection attacks.
In most languages this is trivial, take Perl for example
my $sqlText =~ s/'/\\'/g;
Could it be that easy in Java … not on your life!
Aug
17
Shelling out in Java – beware, not as simple as it first appears!
Filed Under Computers & Tech on August 17, 2005 | 1 Comment
Yes, you should of course avoid ever shelling out in Java, but from time to time shelling out becomes the lesser of two evils (the greater usually being writing a native class) and when that happens you need to be aware of some extra complexity that is often over looked and can result in some very strange and hard to diagnose run-time errors!Many people think that all you have to do to shell out in Java is to do something like the following:
Runtime.getRuntime().exec("/usr/local/bin/convert x.png y.jpg");
This works fine if, and only if, you never assume in the rest of your program that this call completed. Or to put it another way, if your script tries to use the output of the program you shelled out to just launching it in that way could result in inconsistent behavior at run time.
Many programmers who are used to shelling out in Perl or the like assume that Java works in the same way and that the program shelling out will wait till the process it shelled out to completes before moving on. In Perl that is a correct assumption, in Java it is not! The shelled out process runs in a separate thread and Java just carries on execution regardless of what is happening with it’s baby process!
If you need Java to wait because you need to manipulate some outcome from the process you spawned or if you need to find out whether is succeeded or failed you need to do a little more. The following is a function I wrote to shell out properly in a project I am working on, it should be a good enough example for you to work out what to do!
static void executeCommand(String cmd) throws Exception{
try {
Process p = Runtime.getRuntime().exec(cmd);
if(p.waitFor() != 0) {
throw new Exception("The command " + cmd + " returned with an error)");
}
} catch(Exception e) {
// do what ever error handeling you want
}
}
Aug
16
Decapitating java.awt!
Filed Under 42 (Life the Universe & Everything) on August 16, 2005 | 1 Comment
As well as containing very useful functions and objects for the creation of GUIs (useful because Swing extends AWT really) Java AWT (Abstract Windowing Toolkit) also provides a bunch of utility methods and object used for non-GUI related image manipulation via the excellent ImageIO classes that were introduced in Java 1.4. This all sounds great but the problems start when you try to use ImageIO in a scenario where the JVM has no access to an X-server or equivalent to do GUI stuff, then ImageIO breaks down because as soon as you access any AWT component java checks for a place to render to and if it finds none it gives a bizarre and really un-informative exception and dies! Now, you might ask why you would need to manipulate images if you have no GUI, well if you think about it that is the kind of thing that web servers have to do all the time, in fact the blogging software I am using to write this post needs to do that kind of thing all the time (but not in Java of course)!
However, do not despair, deep in the bowels of Java there is a solution and since even Google had some trouble pointing me to it I figured I’d share it with the world!
The key is to decapitate AWT, or, to be more formal to force it to run "headless". If you are just running your application from the command line this is not hard to do at all, you just pass Java a command line argument to tell it to run AWT headless like so:
java xxxxxxx -Djava.awt.headless=true
However, the chances are you won’t be running this kind of application from the command line, in all likelihood you will be trying to do this from within a web server like Tomcat and you can’t just add that -D flag to the Tomcat startup script!
However, after some dissecting of the main tomcat startup script (catalina.sh) I found the solution for Tomcat servers, you need to set up an environment variable called JAVA_OPTS that contains the option and export it in what ever script you are using to start Tomcat. I am running Tomcat on OS X so I did this in my StartupItem for Tomcat (/Library/StartupItems/Tomcat/Tomcat) which now looks like this:
#!/bin/sh
. /etc/rc.common
export JAVA_HOME="/Library/Java/Home"
export CATALINA_HOME="/usr/local/tomcat"
export JAVA_OPTS="-Djava.awt.headless=true"
if [ "${TOMCAT}" = "-YES-" ]; then
ConsoleMessage "Starting Tomcat"
su tomcat - /usr/local/tomcat/bin/startup.sh
fi
So, it really is that simple but I have to say it took me a long to to figure all this out this afternoon when for no apparent reason ImageIO was crashing with some error about a window!