|
|
Step 1: installing jBoss
he first step will be to download, install and test the
jBoss server. At the time of writing the most recent version of jBoss is 2.0.
You can get jBoss from www.jboss.org
Before installing and running the server, you should check that your JDK
installation is working. You will need the JDK binaries directory in
your PATH (this is essential: see below) not just for the user account which is
doing the installation, but also for the user account that will run the server.
If you are running the server as root, you should check that the JDK binaries
are in the PATH even for root (root and ordinary users normally have different
PATH settings). You won't need to specify a CLASSPATH environment variable if
you don't normally have to.
It doesn't matter very much where you install jBoss; my preference is to use
/usr/lib/jboss. If you don't have root access, or would rather not
run untested software as root, jboss will work perfectly well if installed in a
user directory and run as an ordinary user. I will assume in this tutorial that
you are installing in /usr/lib/jboss. If you haven't, change the
paths as appropriate.
jBoss is distributed as a ZIP archive, which isn't a natural format for Linux
users. If you don't have specific un-ZIP software, you can use
jar, like this:
#jar xvf jBoss-2.0.zip
Note that jBoss is not packaged with the directory name at the top of the tree, so you will
need to change to the installation directory before running `jar' as above. You
should end up with a number of directories, named `bin', `lib', etc.
You could try running the server now. Change to the bin directory,
and run
#java -jar run.jar
In a proper installation, the server should start without any error messages or
exceptions being thrown. It will produce about three pages of output on
startup.
The jBoss distribution is supplied with one test Bean, packaged as bank.jar.
This is supplied in the `deploy' subdirectory, which is where Beans are placed
to deploy them. The effect of this is to deploy the `bank' bean when the server
starts up. This is fine the first time, as it tests that the SQL server is
working, but you can usefully move bank.jar out of the
deploy directory when you are sure that everything's OK, and the
server will start up more quickly.
Things to watch out for
If the JDK binaries aren't in the PATH, you will get this error message when
you start the server:
[hypersonic] System.run/init: database is in use by a different process
Obvious, isn't it? If you get this message, the SQL server hasn't started, and
there will be a whole heap of other errors later.
If you get an error message like this:
[AutoDeploy] ...NoClassDefFound: java/lang/reflect/InvocationHandler...
this is because you are using a version of JDK that is too old. The class
java.lang.reflect.InvocationHandler was new in version 1.3.
The jBoss server tries to establish its host's IP number when it starts up.
If it can't do this, you wil see an error message like this:
[Webserver] java.net.UnknownHostException:....
This problem is quite common on systems that get their network configuration
parameters dynamically. For example, if your computer connects to the Internet
by a dial-up connection, and then you close the question, you may very likely
end up with a hostname that doesn't make sense. The simple solution is to reset
your hostname to `localhost' like this:
#hostname localhost
Another common problem is caused by not changing to the `bin' directory before
running the server. This leads to error messages like this:
[DataSource] java.sql.SQLException: FileNotFoundException reading properties
from file: ../conf/instantdb.properties java.io.FileNotFoundException:
/usr/lib/conf/instantdb.properties (No such file or directory)
because the server can't find it's own configuration files.
When you're happy that the server is running correctly, go on to the next step.
|
