Book Image

Mastering Geoserver

By : Colin Henderson
Book Image

Mastering Geoserver

By: Colin Henderson

Overview of this book

Table of Contents (19 chapters)
Mastering GeoServer
About the Author
About the Reviewers

Java requirements

GeoServer is a software server written in Java, and as such it requires Java to be present in our environment. The process to install Java will differ according to our target server's architecture. However, in all cases, the first decision we must make is what version of Java to install and with which package. This is because Java is available in two main packages: Java Development Kit (JDK) and Java Runtime Environment (JRE). JDK, as the name suggests, is used to develop Java applications, while JRE is generally used to run Java applications (though JDK also contains JRE).

There are a number of different versions of Java available. However, the GeoServer project only supports the use of Java 6 (also known as Java™ 1.6) or newer. The most recent version is Java 7 (also known as Java 1.7), and GeoServer can be run against this version of Java. The choice of whether to use Java 6 or 7 will largely be down to either personal preference or specific system limitations such as other software that have dependency on a version. For example, Tomcat 8.0 now requires the use of Java 7 as a minimum. The GeoServer documentation states that Java 7 offers the best performance, and so this is the version we will use.


The upcoming GeoServer 2.6 release will require JRE7 (1.7) as a minimum. At the time of writing, GeoServer 2.6 is at Release Candidate 1.

Prior to Version 2, GeoServer required JDK to be installed in order to work; however, since Version 2, this is no longer a requirement, and GeoServer can run perfectly well using just JRE. The key to manage a successful production environment is to make sure there are no unnecessary software or components installed that might introduce vulnerabilities or increase the management overhead. For these reasons, JRE should be used to run GeoServer. The following sections will describe how to install Java to the Linux and Windows environments.

Installing Java on CentOS 6.3

A well-designed production environment will be as lean as possible in terms of the resources consumed and the overall system footprint; one way to achieve this is to ensure that servers do not contain any more software than is absolutely necessary to deliver its intended function. So, in the case of a server being deployed to deliver mapping services, it should only contain the software necessary to deliver maps.

There are many different flavors of Linux available and all of them are capable of running GeoServer without any issues, after all, Java is cross-platform! The choice of Linux distribution is often either a personal one or a company policy-enforced one. There is a great deal of information available to install GeoServer on a Ubuntu distribution, but very little on installing on a CentOS distribution. CentOS is an enterprise-class distribution that closely follows the development of Red Hat Enterprise Linux, and it is a common installation in organizations. We will use CentOS 6.3, and in keeping with the philosophy of making sure that the server is lean, we will only use the minimal server installation.

By default, CentOS 6.3 comes preinstalled with OpenJDK 1.6 as a result of potential licensing conflicts with the distributing Oracle Java that's preinstalled. The GeoServer documentation states that OpenJDK will work with GeoServer, but there might be issues, particularly with respect to 2D rendering performances. While OpenJDK can be used to run GeoServer, it is worth noting that the project does not run tests of GeoServer against OpenJDK, which means that there is a potential risk of failure if it is used in production.

As mentioned previously, Oracle Java is not packaged for the CentOS platform, and thus we will need to install it ourselves using a generic package direct from Oracle. To download Java, visit the Oracle Technology Network website:

Perform the following steps:

  1. Download the current version of JRE 7 for the Linux platform, choosing the *.rpm file from the download list. At the time of writing, this file is jre-7u51-linux-x64.rpm.


    The eagle-eyed amongst you might spot that this file is for a 64-bit flavor of Linux. GeoServer can be installed on both 32-bit and 64-bit architectures; however, installing to a 32-bit Linux architecture will require downloading the 32-bit version of the file, which at the time of writing is jre-7u51-linux-i586.rpm.

  2. Once we download the package to our server, we need to install it.

  3. Change to the directory where the package is downloaded and execute the following command:

    $ sudo rpm -Uvh jre-7u51-linux-x64.rpm


    This will result in JRE being unpacked and installed to the /usr/java directory. Within this directory, there is a symbolic link called latest, which links to the actual JRE install folder. This symbolic link can be used in place of the lengthier JRE directory name. It is best practice to use the latest link so that the future upgrades of JRE does not cause Java-based software to stop working due to broken references.

  4. Next, we need to tell CentOS that we want it to use Oracle JRE instead of the preinstalled OpenJDK. To do this, we make use of the alternatives command to specify the flavor of Java to use:

    $ alternatives –install /usr/bin/java java /usr/java/latest/bin/java 20000

This tells CentOS that any time the java command is used, it actually refers to the binary contained within the Oracle JRE directory and not the OpenJDK binary. The flavor of Java used by the system can be changed any time running the following command:

$ alternatives –-config java

The alternatives command should present you with the following prompt:

There are 2 programs which provide 'java'.

  Selection    Command
   1           /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
*+ 2           /usr/java/latest/bin/java

Enter to keep the current selection[+], or type selection number:


Downloading the example code

You can download the example code files from your account at for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit and register to have the files e-mailed directly to you.

Depending on the number of programs configured to provide the java command, you will be presented with a list. The program that is currently responding to java is indicated by an asterisk.

In this case, Oracle JRE, which we just installed, is shown to be the active one. If Oracle JRE is not currently selected, then simply enter the number matching the /usr/java/latest/bin/java entry in your list.


An important thing to note here is the command entry for Oracle JRE. Notice how it matches the path that we used for the alternatives --install command. This is important as it means that we can now install future versions or updates of Oracle JRE without having to run the alternatives command again. Where possible, you should use the /usr/java/latest/bin/java path to reference Java, for example, the JAVA_HOME environment variable.

We can now test whether our system is using Oracle JRE issuing the following command:

$ java –version

If all goes well, we should see the following response:

java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

Your version numbers might differ, but the rest should be the same; most importantly, we do not want to see the word OpenJDK anywhere.

Installing Java on Windows Server 2008 R2 SP1

If you target Windows Server in your production environment, life is a little simpler than it is for the users of Linux. For the purposes of this book, we will use Windows Server 2008 R2 SP1 Standard Edition, however other versions of Windows Server that can have Java installed should also work fine.

Once again, we will adopt the best practice to use Oracle JRE, and again we will use Version 1.7. Go ahead and download the Windows package for JRE from Oracle's Technology Network website:

At this point, we have a decision to make about which JRE installer to download, 32-bit or 64-bit. Making the right decision now is important as the choice of 32-bit versus 64-bit will have consequences later when configuring GeoServer. In the next section, we will discuss the installation of Apache Tomcat, which has a dependency on Java, in order to run GeoServer.

In the Windows environment, the Apache Tomcat installer will automatically install a 32-bit or 64-bit Windows Service based on the installed Java. So, a 64-bit installation of Java will mean that the Apache Tomcat service will also be installed as 64-bit.

The three factors influencing the choice of a 32-bit or 64-bit Java are:

  • The architecture on which you run Windows

  • Java VM memory configuration considerations

  • The use of native JAI and JAI Image I/O extensions

Hopefully, the first reason is self-explanatory. If you have a 32-bit version of Windows installed, you can only install a 32-bit version of Java. If you have a 64-bit Windows installation, then you can choose between the two versions. We install to Windows Server 2008 R2 SP1, which is only available in 64-bit; this means that the processor architecture or Windows is not a limitation. In this case, the decision now comes down to the memory configuration and use of native JAI and JAI Image I/O extensions.

The memory consideration is an important decision since a 32-bit process, irrespective of whether it runs on a 32-bit or 64-bit processor architecture, can only address a maximum of 2 GB memory. Therefore, if we want to maximize the available server memory, we will need to consider using the 64-bit version of Java. However, the JAI and JAI Image I/O extensions are only available on the Windows platform as 32-bit binaries. If we choose the 64-bit Java, then we will not be able to use the extensions, which can be an issue if we plan on using our server to provide predominantly raster datasets. The native JAI and JAI Image I/O extensions can provide a significant performance increase when performing raster operations, in other words, responding to WMS requests.

Getting the most out of a production environment is as much about maximizing resource utilization as anything else. If we have a server with lots of memory, we can use the 64-bit Java and allocate it a large chunk of memory, but then the only real advantage this provides is that it will allow us to do more concurrent raster operations. The maximum number of concurrent requests will still be limited by other factors, which might not be the most efficient use of server resources. An alternative approach is to scale-up by running multiple instances of GeoServer on the server. This is discussed in more detail later in this chapter. Scaling-up means that we can maximize the usage of server resources (memory) without compromising on our ability to utilize the native JAI and JAI Image I/O extensions.

To install the 32-bit version of Java, perform the following steps:

  1. From the Oracle download page, choose the 32-bit Java installer, which at the time of writing is jre-7u51-windows-i586.exe, and save it to a local disk.

  2. Open the folder where you saved the file, right-click on the file, and choose the Run as administrator menu item:

  3. Accept all Windows UAC prompts that appear and wait for the Java installation wizard to open.

  4. The installer will want to install Java to a default location, usually C:\Program Files (x86)\Java\jre7, but if you want to install it to a different folder, make sure to tick the Change destination folder checkbox placed at the bottom of the dialog:

  5. Click on the Install button. If you did not tick the box to change the destination folder, then the installation will start.

  6. If the changed destination checkbox was ticked, clicking on the Install button will prompt for the location to install to.

  7. Specify the location you want to install to, and then click on the Next button; the installation starts.

  8. If the installation is successful, you will be greeted with the following screen:

Closing the installation wizard will launch a web browser where the installation of Java can be verified by the steps given on the page loaded after Java installation.