"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Upgrading existing GeoServer

Contents

Related pages


1. Overview

This page is intended to guide users wishing to upgrade their existing installation of GeoServer. Take note that this guide will serve as a guide only and will not provide a step by step instruction on how to upgrade your instance of GeoServer as every web container set up and every server set up can vary greatly. This guide will be using Tomcat and the GeoServer instance build 2011-09-26 as an example guide to upgrading.

2. Upgrading GeoServer

2.1 Strategy

Again, there are different strategies and this guide will discuss a few of them. The choice will once again depend on the organisation for obvious reasons.

2.1.1 Parallel swapping

As the heading suggests, this strategy will involve deploying a second instance of GeoServer, either on a separate machine or with a different instance name.

The new installation of GeoServer should be tested and once successful, the original instance of GeoServer can be swapped to the new installation. The benefit of this is that it can easily be rolled back if something goes wrong during installation and the new installation of GeoServer can be tested before moving forward.

Running 2 instances of GeoServer in parallel will double the resources required and it will add additional load on the machine; therefore if resources are scarce, this strategy should be avoided.

2.1.2 Remove and install

This is a straight forward strategy which will require the user to remove (remember to back it up to another location) the old installation and perform a fresh installation of the newer version of GeoServer.

The drawback to this is a potential risk that the user may not be able to roll back if something goes wrong during the fresh installation.

This is an alternate solution if resources are limited; else always choose parallel swapping over this strategy.

2.2 Configuration files

Make sure there is a backup of the following configuration files from the old instance of GeoServer so that it can be referred to when needed.

2.2.1 A connection to your database (most likely in the form of a JNDI database resource)

Since it is a upgrade of a existing installation of GeoServer, there should already be a JNDI configuration set somewhere. Try looking in
  • <tomcat>/conf/context.xml
  • <tomcat>/conf/server.xml(not a recommended place to place your JNDI)
  • webapps/geoserver/WEB-INF/web.xml
Refer to http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html for more information.

If JNDI is configured in <tomcat>/conf, it means the configuration is set for web container wide usage; therefore your new installation of GeoServer should be already set to use its resources. If the configuration is set within your application e.g. webapps/geoserver/WEB-INF/web.xml, this means the resource configuration is specific for that particular application.

2.2.2 App-schema properties file for interpolation.

This file should be placed in the classpath of your GeoServer instance. Most commonly placed in

webapps\geoserver\WEB-INF\classes\app-schema.properties

2.2.3 Data Directory

Look in tomcat\webapps\geoserver\WEB-INF\web.xml. There should be an entry like the one shown below.
<context-param>       
    <param-name>GEOSERVER_DATA_DIR</param-name>        
    <param-value>C:\VWork\testing\testData\pirsa\data</param-value>    
</context-param> 

This entry tells us where the directory is located; therefore ensure a backup copy of this data directory.

2.2.4 Plugins

This will require the user to have knowledge of their overall system architecture such as the type of database they are using, the plugins they used for GeoServer. The commonly used plugins are:
  • app-schema-plugin.zip
  • oracle-plugin.zip
  • myql-plugin.zip
  • sqlserver-plugin.zip

2.3 GeoServer Artifacts

The GeoServer artifacts including the plugins can be downloaded from http://downloads.auscope.org/geoserver-build/release-candidates/2011-09-26/.

2.4 Upgrade Instructions

2.4.1 Ensure the configuration are provided

Doesn't matter which strategy is chosen, ensure the following criteria are met:
  • A valid JNDI connection from previous installation to your database configured
  • A valid app-schema.properties from previous installation in your webapps\geoserver\WEB-INF\classes\app-schema.properties
  • GeoServer should be configured to read from a copy of your data directory from previous installation which can be configured in tomcat\webapps\geoserver\WEB-INF\web.xml
  • All the required plugins which can be found in http://downloads.auscope.org/geoserver-build/release-candidates/2011-09-26/

2.4.2 Install GeoServer

The next step is to install a copy of GeoServer. Refer to GeoServerDeployment which will guide you on new installation. Since it is an upgrade process, a lot of the work should already be done.

In a very brief summary, below are the steps required.
  1. Download war file and plugins from http://downloads.auscope.org/geoserver-build/release-candidates/2011-09-26.
  2. Provide configuration as stated in 2.4.1
  3. Start tomcat.
  4. Go to http://localhost:8080/manager/html.
  5. Deploy war file.
The new installation of GeoServer should be good to go smile

3. Configuration

3.1 General Configuration

Please refer to Geoserver user documentation on user configuration.

3.2 App schema wms configuration.

Configuring app schema to provide wms support is fairly straight forward. A wms layer file will need to be configured for Geoserver to pick up wms configuration. Visit the documentation for a detailed guide on how to do this.

However, using wms support for app schema will require Joining Support for performance for better performance.

If the layer have been correctly configured, it can be previewed on the GeoServer gui for layer preview.

layersPreview.png

Althought wms support for app schema is available since 2.2, we would advise the download of the latest stable release as there are many bug fixes since its inception.

3.3 Auscope portal WMS/WFS configuration

3.3.1 Keyword Association

For WMS/WFS geoserver configuration to work with the Auscope Portal, we need to provide a way of telling the portal that this wms layer and this wfs are linked. GeoServer does not provide this therefore we need to use some other method for portal to detect this.

In your configuration folder, each featureType in the workspace will contain a featureType.xml. Alter this file to include a keyword that will be unique to identify this layer as yours.

keywords.png

3.3.2 : Network between GeoServer and Auscope Portal

We have 2 options of providing dynamic SLD to geoserver. One is the embed the SLD file to the url which can be extremely messy or secondly provide a url to links to a SLD file. The second option is a cleaner approach but that would require a open port network connection between GeoServer to the portal. The port to use will depend on the port that the Auscope portal is currently using. At the moment it is port 80 and is unlikely to change in the forseeable future.

4. Support

Help is always given to those who need it.

SISS mailing list: https://lists.csiro.au/mailman/listinfo/siss

GeoServer mailing list: http://geoserver.org/display/GEOS/Mailing+Lists
Topic attachments
I Attachment Action Size Date Who Comment
keywords.pngpng keywords.png manage 10.0 K 15 Mar 2013 - 14:20 VictorTey  
layersPreview.pngpng layersPreview.png manage 19.3 K 06 Mar 2013 - 16:46 VictorTey  
Topic revision: r10 - 23 Apr 2013, RiniAngreani
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).