GeoServer 2.23.5 release is now available with downloads (bin, war, windows), along with docs and extensions.

This is the last planned maintenance release of GeoServer 2.23.x, providing existing installations with minor updates and bug fixes. Sites using the 2.23.x series are encouraged to upgrade to GeoServer 2.24.x, or eventually wait next month, for the 2.25.0 release, and upgrade their installation, with the help of the upgrade guide.

GeoServer 2.23.5 is made in conjunction with GeoTools 29.5, and GeoWebCache 1.23.4.

Thanks to Andrea Aime (GeoSolutions) for making this release.

Security Considerations

This release addresses security vulnerabilities and is considered an essential upgrade for production systems.

• CVE-2024-23634 Arbitrary file renaming vulnerability in REST Coverage/Data Store API (Moderate).

See project security policy for more information on how security vulnerabilities are managed.

Release notes

New Feature:

• GEOS-11225 AuthKey synchronize the user/group automatically
• GEOS-11279 metadata: allow same field on multiple tabs

Improvement:

• GEOS-11213 Improve REST external upload method unzipping
• GEOS-11246 Schemaless plugin performance for WFS
• GEOS-11260 JNDI tutorial uses outdated syntax
• GEOS-11276 Use style_body to define CSS style for a layer
• GEOS-11288 Improve input validation in ClasspathPublisher

Bug:

• GEOS-11174 GWC rest api returns erroneous truncated response when gzip http encoding is enabled
• GEOS-11205 Layer page: style image fails if it is in isolated workspace
• GEOS-11250 WFS GeoJSON encoder fails with an exception if an infinity number is used in the geometry
• GEOS-11255 Multiple inserts in WPS with different idGen strategies does not work
• GEOS-11256 Cannot retrieve LegendGraphic from a PostGIS datastore with ‘hideEmptyRules’ and ‘Support on the fly geometry simplification’ enabled
• GEOS-11278 metadata: only selected tab is submitted
• GEOS-11285 GWC REST Content-Encoding gzip returns broken response
• GEOS-11291 GeoFence: Cleanup stale log4j references

For the complete list see 2.23.5 release notes.

Community Updates

Community module development:

• GEOS-10933 keycloak logout NPE
• GEOS-11290 With Oauth enabled, anon users get random auth requests

Community modules are shared as source code to encourage collaboration. If a topic being explored is of interest to you, please contact the module developer to offer assistance.

About GeoServer 2.23 Series

Additional information on GeoServer 2.23 series:

• GeoServer 2.23 User Manual
• Drop Java 8
• GUI CSS Cleanup
• Add the possibility to use fixed values in Capabilities for Dimension metadata
• State of GeoServer 2.23
• GeoServer Feature Frenzy 2023
• GeoServer used in fun and interesting ways
• GeoServer Orientation

Release notes: ( 2.23.5 | 2.23.4 | 2.23.3 | 2.23.2 | 2.23.1 | 2.23.0 | 2.23-RC1 )

GeoSpatial Techno is a startup focused on geospatial information that is providing e-learning courses to enhance the knowledge of geospatial information users, students, and other startups. The main approach of this startup is providing quality, valid specialized training in the field of geospatial information.

( YouTube | LinkedIn | Facebook | Reddit | X )

A Comprehensive Guide to publishing a Shapefile in GeoServer

In this session, we want to talk about “How to Publish Shapefile in GeoServer” comprehensively. If you want to access the complete tutorial, simply click on the link

Introduction

The Data section contains configuration options for all the different data-related settings that GeoServer uses to access and publish geospatial information. It also describes how to load, manage, and publish data in the GeoServer web interface. Each section contains the specific pages that provide add, view, edit, and delete capabilities.

Note. In this blog post, we used GeoServer version 2.20.0.

Workspaces

A Workspace serves as a means to group and organize similar layers together. It enables you to associate multiple layers and stores with a single workspace. Each workspace can be managed independently, with its own security policies, data administrator, and web services. Generally, a workspace is created for each project, along with its corresponding stores and layers.

Add a workspace

To create a new workspace, navigate to Data > Workspaces page. Click on the Add new workspace, then you have to enter a Workspace Name and Namespace URI.

• Workspace Name: It is an identifier describing your project. It must not exceed ten characters or contain spaces (due to use as an XML “prefix” when downloading content).
• Namespace URI: URI stands for Uniform Resource Identifier, is a formal system for uniquely identifying resources, and consists of two types: URL and URN. A Namespace URI does not need to point to an actual location on the web and only needs to be a unique identifier.
• Default Workspace: This setting is useful when you only have one workspace defined. The setting allows users to communicate with the web service using just the layer name (rather than prefix:layer name required when managing hundreds of workspaces). select the Default Workspace checkbox to assign this as your default workspace.
• Sometimes the same feature type needs to be published multiple times with a different mapping and with the same name. This can be done in GeoServer using Isolated Workspaces functionality.

Press the Submit button to save your new workspace.

Edit a workspace

To view or edit a workspace, click on the Workspace name, then a workspace configuration page will be displayed.

• For Settings, select the Enabled checkbox to customize the settings and contact details for the workspace level. This allows you to define an introduction to your workspace, and override the global settings for your workspace.
• Use the checkbox located next to each service to override the Global Settings for the associated service. Once enabled, clicking on the Services link will open the settings page for the service, allowing default values for the service title, abstract, and other details to be supplied.
• The Security tab allows to set data access rules at the workspace level. To create/edit the workspace’s data access rules, check/uncheck checkboxes according to the desired role.

Remove a workspace

To remove a workspace, select it by clicking the checkbox next to the workspace. Multiple workspaces can be selected, or all can be selected by clicking the checkbox in the header. Click the Remove selected workspace(s) link. Now you will be asked to confirm or cancel the removal.

Pressing OK removes the selected workspace(s).

Stores

The Stores manage the connection parameters between GeoServer and the data sources where your spatial data reside. They provide a mechanism for GeoServer to connect to various data repositories, including file systems, databases, and cloud storage services. Each store represents a unique data source and has its configuration settings.

Add a store

To add a Store, navigate to Data > Stores page. Click on Add new store, then you will be prompted to choose a data source. GeoServer supports several different data formats, but they are classified into three types: “Vector data”, “Raster data”, and “Cascaded Services”.

• Vector data formats include Shapefile, GeoPackage, PostGIS, and Properties. The most common and widely used option is Shapefile.
• Raster data formats include ArcGrid, GeoPackage, GeoTIFF, ImageMosaic, and WorldImage. The most used and well-known are the GeoTIFF and the WorldImage. GeoTIFF is a spatial extension of the “TIFF” format and tags image files with geographic information. A WorldImage is similar, but georeferencing information is saved in an external text file.
• Cascaded Services include WFS, WMS, and WMTS. GeoServer can proxy a remote Web Map Service and Web Map Tile Service and load it as a store in GeoServer.

Other data sources are supplied as GeoServer extensions. Extensions are downloadable modules that add functionality to GeoServer. Click the appropriate data source to configure the store, because the connection parameters vary depending on data format.

To create a Shapefile data store, follow these steps:

• Select the desired workspace from the drop-down menu.
• Enter the Data Source Name. Make sure the “Enabled” checkbox is selected. Otherwise, access to the store along with all the datasets defined, will be disabled for it.
• In the “Shapefile location”, click on the Browse link to define the location of the shapefile.
• The DBF file format has a field for character encoding, but it doesn’t always accurately indicate the actual encoding used. As a result, it is important to specify the DBF character set correctly when decoding strings to ensure accurate interpretation of the data.

When finished, press the Save button. Now it will automatically redirect to the Add New Layer page, which will be completely described in the Layer section. Next, we will explain how to edit and remove the store.

Edit a store

To view or edit a store, click on the Store name. A Store configuration page will be displayed. The exact contents of this page depend on the specific format of the Store. After your configuration is modified, press the Save button.

Remove a store

To remove a Store, click the checkbox next to the store. Multiple stores can be selected, or all can be selected by clicking the checkbox in the header. Click the Remove selected stores. You will be asked to confirm the removal of the configuration for the store(s) and all resources defined under them.

Pressing OK removes the selected Store(s), and returns to the Stores page.

Layers

From the administration interface, navigate to the Data > Layers page. On this page, you can view and edit existing layers, add a new layer, or remove a layer. It also shows you the type of layers in the Type column, with a different icon for vector and raster layers, according to the geometry shape. The Title, Workspace, and Store values of each layer are shown.

Add a layer

Clicking the Add a new layer, brings up a New Layer Chooser panel. The menu displays all currently enabled stores. If you want to add a new layer for a published resource, click on Publish Again. Note that when republishing the name of the new layer may have to be modified to avoid conflict with an existing layer.

The beginning sections (Basic Resource Info, Keywords, and Metadata link) provide metadata, specifically textual information that makes the layer data easier to understand and work with. The metadata information will appear in the capabilities documents which refer to the layer. These options are:

• Name: The identifier used to reference the layer in WMS requests that are filled automatically. Note that for a new layer for an already-published resource, the name must be changed to avoid conflict.
• Enabled: A layer that is not enabled won’t be available to any kind of request, it will just show up in the configuration and in REST config.
• Advertised: A layer is advertised by default. A non-advertised layer will be available in all data access requests (for example, WMS GetMap, WMS GetFeature) but won’t appear in any capabilities document or the layer preview.
• Title: The human-readable description to briefly identify the layer to clients that filled automatically. GeoServer provides an item for the title and abstract and describes how to specify metadata in different languages. By default, it’s disabled and can be enabled from the i18n checkbox.
• Abstract: It describes the layer in detail.
• Keywords: List of short words associated with the layer to assist catalog searching. To add a new keyword, enter your keyword, then press the Add Keyword button to add it.
• Metadata & Data Links: It allows linking to external documents that describe the data layer. The Type input provides a few example types, like FGDC or ISO19115, but allows any other type to be declared. Format provides its mime type, while URL points to the actual metadata.

A Coordinate Reference System (CRS) defines how georeferenced spatial data relates to real locations on the Earth’s surface. GeoServer needs to know the CRS of your data. This information is used for computing the latitude/longitude bounding box and reprojecting the data during both WMS and WFS requests.

• Native SRS: Specifies the coordinate system the layer is stored in. Clicking the projection link displays a description of the SRS.
• Declared SRS: Specifies the coordinate system GeoServer publishes to clients.
• SRS Handling: Determines how GeoServer should handle projection when the two SRSes differ. Possible values are:
  • Force declared: This is the default option and normally the best course of action. Use this option when the source has no native CRS, has a wrong one, or has one matching the EPSG code.
  • Reproject from native: This setting should be used when the native data set has a CRS that does not match any official EPSG. E.g. Lambert Conformal Conic to WGS84.
  • Keep native: This is a setting that should be used in very rare cases. Keeping native means using the declared one in the capabilities documents, but then using the native CRS in all other requests.

The Bounding Box determines the extent of the data within a layer. It includes two items: “Native Bounding Box” and “Lat/Lon Bounding Box”. Generate the bounds for the layer by pressing the Compute from data and Compute from native bounds button in the Bounding Boxes section.

Vector layers have a list of the “Feature Type Details”. These include the Property and Type of a data source. Remember that, if you want to change your data by ArcGIS or QGIS, like add or remove features or fields, or edit the attribute table contents, there is no need to create a layer again in the GeoServer, just press the Reload feature type, so your layer will be updated.

Remember that GeoServer, by default, publishes all the features that are currently available in the layer. However, if you wish to limit the features to a specific subset, you can achieve this by specifying a CQL filter in the configuration. Upon completing the layer configuration, finalize the process by pressing the Save button. This action will create the layer based on the specifications you have provided.

Edit a layer

To view or edit a layer, click on the Layer Name from the Layer page. A layer configuration page will be displayed. After your configuration is modified, press the Save button.

Remove a layer

To remove a layer, select the checkbox next to the layer. Multiple layers can be selected, or all can be selected by clicking the checkbox in the header. By clicking the Remove selected layers link, you will be asked to confirm the removal of the configuration for the layer(s) and all resources defined under them.

Press OK removes the selected layer(s), and returns to the Layers page.

GeoServer 2.24.2 release is now available with downloads (bin, war, windows), along with docs and extensions.

This is a stable release of GeoServer recommended for production use. GeoServer 2.24.2 is made in conjunction with GeoTools 30.2, and GeoWebCache 1.24.2.

Thanks to Jody Garnett (GeoCat) for making this release, everyone who contributed, and to Georg Weickelt and Peter Smythe for preflight testing.

Security Considerations

This release addresses security vulnerabilities and is considered an essential upgrade for production systems.

• CVE-2024-23634 Arbitrary file renaming vulnerability in REST Coverage/Data Store API (Moderate).

See project security policy for more information on how security vulnerabilities are managed.

Release notes

Improvement:

• GEOS-11213 Improve REST external upload method unzipping
• GEOS-11246 Schemaless plugin performance for WFS
• GEOS-11219 Upgraded mail and activation libraries for SMTP compatibility

Bug:

• GEOS-9757 Return a service exception when client provided WMS dimensions are not a match
• GEOS-11051 Env parametrization does not save correctly in AuthKey extension
• GEOS-11223 Layer not visible in preview/capabilities if security closes the workspace, but allows access to the layer
• GEOS-11224 Platform independent binary doesn’t start properly with default data directory
• GEOS-11235 preauthentication filters - session reuse even after having logout
• GEOS-11241 ModificationProxy breaks information hidding on CatalogInfo.accept(CatalogVisitor) exposing the proxied object
• GEOS-11250 WFS GeoJSON encoder fails with an exception if an infinity number is used in the geometry
• GEOS-11255 Multiple inserts in WPS with different idGen strategies does not work

Task:

• GEOS-11220 Upgrade Hazelcast from 5.3.1 to 5.3.6
• GEOS-11245 Update OSHI from 6.2.2 to 6.4.10

For the complete list see 2.24.2 release notes.

Community Updates

Community module development:

• GEOS-10933 keycloak logout NPE

Community modules are shared as source code to encourage collaboration. If a topic being explored is of interest to you, please contact the module developer to offer assistance.

About GeoServer 2.24 Series

Additional information on GeoServer 2.24 series:

• GeoServer 2.24 User Manual
• Control remote HTTP requests sent by GeoTools/GeoServer
• State of GeoServer 2.24.1 (foss4g-asia presentation)
• Multiple CRS authority support, planetary CRS
• Extensive GeoServer Printing improvements
• Upgraded security policy

Release notes: ( 2.24.2 | 2.24.1 | 2.24.0 | 2.24-RC )

GeoSpatial Techno is a startup focused on geospatial information that is providing e-learning courses to enhance the knowledge of geospatial information users, students, and other startups. The main approach of this startup is providing quality, valid specialized training in the field of geospatial information.

( YouTube | LinkedIn | Facebook | Reddit | X )

GeoServer About & Status along with practical guides

In this session, we would like to talk around the “About & Status” section of GeoServer. If you want to access the complete tutorial, simply click on the link

Introduction

The “About & Status” section of GeoServer provides information about runtime variables and how GeoServer is described to clients that connect to it. In other words, this section provides access to GeoServer diagnostic and configuration tools and can be particularly useful for debugging.

• “Server Status”: view server configuration and run-time status.
• “GeoServer Logs”: see GeoServer log output for error diagnosis.
• “Contact Information”: manage public contact details for WMS server.
• “About GeoServer”: access GeoServer docs, homepage, and bug tracker. You do not need to be logged into GeoServer to access this page.

Server Status

The “Server Status” page, gives you a summarized overview of the main configuration parameters and information about the current state of the GeoServer. It has three tabs:

• The “Status” tab, provides a summary of server configuration parameters and run-time status.
• The “Modules” tab, provides the status of the various modules installed on the server.
• The “System Status” tab, provides extra information about the system environment GeoServer is running in.

Status Field Descriptions

This page describes the current status indicators:

• Data directory: It shows the path to the GeoServer data directory. The procedure for setting the location of the GeoServer data directory is dependent on the type of GeoServer installation. When running a GeoServer Web Archive inside a servlet container, the data directory can be specified in several ways. The recommended method is to set a servlet context parameter. To specify the data directory using a servlet context parameter, create the “context-param” element in the “WEB-INF/web.xml” file for the GeoServer application. After you change the path of the data directory, log in to GeoServer again. Now you can see the new path of the data directory.
• Locks: When using Transactional Web Feature Service (WFS-T), clients can edit feature types. To prevent data corruption, GeoServer locks the data during transactions. If the number is greater than one, there are active transactions. Clicking “Free Locks” resets a hung editing session and removes any abandoned locks.
• Connections: This shows you the number of vector data store connections. Vector data stores are repositories configured for the persistence of features.
• Memory Usage: This shows you how much memory GeoServer is using. You can manually run the garbage collector by clicking the Free Memory button, so it cleans up memory marked for deletion.
• JVM Version: This is the version of the “Java Virtual Machine” that the GeoServer is using.
• Java Rendering Engine: It shows the rendering engine used for vector operations.
• Available Fonts: This is a list of the fonts seen by the GeoServer. Fonts are useful to render labels for spatial features. Selecting the link will show the full list. To add custom fonts to the GeoServer, first, you have to download your favorite fonts from the web, then copy them to the “Java installation folder\jre\lib\fonts”. After restarting the Apache Tomcat software, the new fonts will be added to the Available Fonts list.

In programming, to improve the speed and performance of the program, each of the various tasks and parts of the application can be assigned to a thread. The Thread Pool template helps conserve resources in a multithread application and also places parallel computations in a specific predefined framework. When using the Thread Pool, we can perform concurrent tasks in parallel form. Here are the titles of GeoServer’s ThreadPoolExecutor parameters: ThreadPoolExecutor Core Pool Size , ThreadPoolExecutor Max Pool Size , ThreadPoolExecutor Keep Alive Time(ms)

• Update Sequence: This option shows you how many times the server configuration has been updated.
• Resource cache: GeoServer does not cache data, but it does cache connection to stores, feature type definitions, external graphics, font definitions, and CRS definitions as well. The “Clear” button forces those caches to empty and makes GeoServer reopen the stores and re-read image and font information, as well as the custom CRS definitions stored in: ${GEOSERVER_DATA_DIR}/user_projections/epsg.properties
• Configuration and catalog: This option is very useful to update the configuration without having to restart the service. If the configuration on the disk becomes outdated due to external changes, you can refresh it by loading the latest data from the disk.

Module Field Descriptions

In GeoServer, a module can fall into one of three classes:

• Core, those modules that are visible by default in the Modules tab that GeoServer requires to function and are distributed with the main GeoServer distribution.
• Extension, those modules that add functionality to GeoServer. They are installed as add-ons to the base GeoServer installation. After you download and install these extensions, they are added to the Geoserver modules list. For example WPS extension
• Community, those modules that are generally considered experimental and are often under development. For that reason, Unlike the official extensions, these modules are not released and stored on SourceForge when an official GeoServer release is produced.

Every module added to GeoServer has its origin as a community module. If the module becomes stable enough it will eventually become part of the main GeoServer distribution either as a core module or as an extension.

System Status Field Descriptions

System Status adds some extra information about the system in the GeoServer status page in a tab named System Status and makes that info queryable through the GeoServer REST interface. This info should allow an administrator to get a quick understanding of the status of the GeoServer instance. If the System status tab is not present, it means that the plugin was not installed correctly. The System status tab content will be refreshed automatically every second.

GeoServer Logs

The “GeoServer Logs” page, lets you read the messages, warnings, and errors contained in the log file. According to the current logging settings, you can find more information about the requests clients send to GeoServer and how it processes them. You can only read the last 1,000 lines by default from the console. You can also change this setting, but if you need to access the entire log content, we would strongly suggest accessing it with a text editor.

You can use the “Download the full log file” link placed just under the text console, or access the log file directly from this path: “geoserver_data_dir/logs/geoserver.log”

Contact Information

The “Contact Information” page, is used in the Capabilities document of the WMS server and is publicly accessible. GeoServer provides an item to describe this information and metadata in different languages. By default, it’s disabled and can be enabled from the i18n checkbox. You can complete this form with the relevant information and press the Save button to save your information.

About GeoServer

The “About GeoServer” section, provides a brief description of geoserver and build information such as GeoServer Version, Git Revision, Build Date, GeoTools Version, and GeoWebCache Version. Also, this section provides links to the GeoServer Documentation, Wiki, and Issue Tracker. Remember that, You do not need to be logged into GeoServer to access this page.

Happy new year and welcome to 2024 from the GeoServer team!

The GeoServer team is doing something different this year: sharing our roadmap plans and asking our community for resources (participation and funding) to meet our 2024 goals.

The GeoServer project is supported and maintained thanks to the hard work of volunteers and the backing of companies providing professional support.

We are seeking a healthy balance in 2024 and request increased support in the following areas:

• Maintenance: GeoServer was started in 2001 by a non-profit technology incubator. Subsequent years has seen the project supported by larger companies with investors and venture capital. This support is no longer available - and without this cushion we must rely on our community to play a greater role in sharing ongoing maintenance activities.

  The team has provided a great response with increased use of automation, quality assurance tools, and dropping modules such as SAML that have not attracted participation. Keep in mind that participation, not popularity, determines what functionality is available each release.

  However maintenance costs for software are increasing in 2024. Expectations for prompt response to security vulnerabilities have increased. This causes the components used by GeoServer to be updated more frequently, and with greater urgency.

  Volunteers can answer questions on geoserver-user list, reproduce issues as they are reported, and verify fixes.

  Developers are encouraged to get started by reviewing pull-requests to learn what is needed, and then move on to fixing issues.

  Trusted volunteers can help mind geoserver-security email list, and help reproduce vulnerabilities as they are reported. We also seek developer capacity and funding to address confirmed vulnerabilities.

• Testing: In 2023 we saw a greater response to our call for release-candidate testing. This was very much appreciated given the technical-challenge undertaken in 2023. However this response was largely taken up by downstream projects, where we could personally create a ticket in their issue trackers discussing the technical risk and asking for help.

  Volunteers and service providers are asked to help test release-candidates in March 2024 and September 2024. The GeoServer team operates with a time-boxed release model so it is predictable when testing will be expected.

• Sponsorship: In 2023 we made a deliberate effort to “get over being shy” and ask for financial support, setting up a sponsorship page, and listing sponsors on our home page.

  We received $1000 USD. You might think of this as a poor response.

  North River Geographic Systems Inc provided funding to thank Andrea Aime for speaking at an event with no clear expectation of sponsorship. How 2 Map sponsorship reflects Jody’s personal company being used for screen snaps on how to badge a github repository as supporting OSGeo.

  With this in mind - no funds were directly raised in answer to our 2023 call for financial support. So this is actually a terrible response.

  We ask for your financial assistance in 2024 (see bottom of page for recommendations).

The above priorities of maintenance, testing and sponsorship represent the normal operations of an open-source project. This post is provided as a reminder, and a call to action for our community.

Roadmap Planning

We have shared the following roadmap planning information in foss4g presentations in 2023, and it is time to share these goals with a wider audience as part of this blog post.

This is a brave step for the project: as we learned early on that placing a goal on a roadmap can be taken as an indication that funding is already secured. We even had a negative example where placing a goal on a roadmap resulted in the interested party withdrawing (as they understood that the community was now going to do the work instead!)

With this in mind here are our priorities for 2024:

• Migrate to spring-framework-6 (Deadline December 2024)

  GeoServer uses the spring-framework 5.3 which will reach end-of-life in December 2024. This provides motivation for all roadmap planning in calendar year 2024.

  We are already getting concerned inquiries in response to CVE scans recommending upgrading to spring-framework 6. We look forward to your support of this activity.

  In order to stay on a supported version of spring-framework we need to migrate to spring-framework 6 for December 2024.

• Migrate to spring-security 6

  The spring-security framework is used by GeoServer for integrating with a number of systems.

  • Central Authentication Service (CAS)
  • Lightweight Directory Access Protocol (LDAP)

  Use of spring-framework 6 and above requires the use of spring-security 6.

• Remove spring-security-oauth plugin

  A number of popular community modules are built on spring-security-oauth plugin:

  • OAuth2 google
  • OAuth2 github
  • OAuth2 geonode
  • OAuth2 OpenID Connect

  Support for OAuth2 in GeoServer is based on the deprecated spring-security-oauth library. The same functionality is now provided by spring-security itself, but exposing a different API, making the GeoServer plugin incompatible.

  Our GeoServer security integrations will need to be rewritten to use the spring-security framework directly.

  The good news is that this activity is available to be worked on immediately with spring-security 5.8 and then migrated to spring-security 6. Other projects such as GeoNetwork have already made the transition.

  The use of spring-security 6 requires removing spring-security-oauth plugin.

• Remove spring-security-keycloak plugin

  A community module offering keycloak integration will need to be rewritten or replaced.

  The Keycloak team has announced that their spring-security-keycloak plugin has reached end-of-life and will be removed from a future release of Keycloak. They recommend migrating to OAuth2/OpenID Connect support from spring-security 6.

  We recommend those using the spring-security-keycloak plugin to join forces in development and testing of OAuth2/OpenID Connect integration.

  The use of spring-security 6 requires removing spring-security-keycloak plugin.

• Migrate to Jakarta Enterprise Edition

  GeoServer is a Java Web Application comprised of a number of “servlets” that can be run by an application server. The specification of how these components work together is defined by the Java Enterprise Edition specification. This specification is now managed by the Eclipse Foundation as Jakarta Enterprise Edition.

  With the change to Jakarta Enterprise Edition we expect a number of compatibility issues:

  • The charts extension is based on eastwood charts last updated in 2008.

    This library is not compatible with Jakarta Enterprise Edition and will need to be replaced.

  • mapfish-print-v2

    This library is not compatible with Jakarta Enterprise Edition and will need to be updated or replaced.

  Application Servers that support Jakarta Enterprise Edition:

  • Apache Tomcat 10.1 / Jakarta Enterprise Edition 10 / Servlet 6 / Java 17+
  • Jetty 12.0 / Jakarta Enterprise Edition 10 / Servlet 6 / Java 17+

  When ready we will need volunteers to test on the new application servers and update the binary release and documentation to reflect the new environment. Organizations operating in a managed environment may wish to pursue permission to operate Tomcat 10.1 ahead of this planned change.

  The spring-framework version 6 uses the newer Jakarta Enterprise Edition specification.

• Upgrade to Apache Wicket 10

  Apache Wicket user-interface framework is used for the GeoServer Admin console screens.

  Brad Hards has started this activity by going to the intermediate goal of Wicket 9, and will require a fleet of testers to perform A/B testing of each screen. This is an impressive undertaking, in 2016 we did an entire round of fundraising to assemble a team sprint when updating from Apache Wicket 1.4. to Wicket 7.x

  Volunteers can help Brad test Wicket 9 now, and when the transition to Wicket 10 is complete a second round of A/B testing will be scheduled

  The use of Jakarta Enterprise Edition requires the use of Apache Wicket 10.

• Upgrade to Java 17

  GeoServer is presently compiled with Java 11 LTS, with the result tested on Java 11 LTS, Java 17 LTS, and soon Java 21 LTS.

  With the change to Java 17 we expect a number of libraries we use to require updating or replacing.

  GeoServer is presently building on Java 17, however documentation will need to be updated when Java 11 support is dropped. Organizations may wish to pursue permission to operate Java 17 LTS ahead of this planned change.

  The spring-framework 6 and Jakarta Enterprise Edition application servers require Java 17 as a minimum.

• Migrate to ImageN 1.0

  The Java Advanced Imaging library is used as the engine for our image and raster processing capabilities. This library reached end-of-life with the last JAI 1.1.3 release in 2005.

  This library has received considerable investment from our community with GeoSolutions heading up the JAI-EXT project to better work with geospatial datasets, operations and analysis including recent support for hyperspectral imagery.

  We have been planning for this migration for some time:

  1. Boundless worked with LocationTech to outline the creation of a new “Raster Processing Engine” library (with estimate of $150k). This library was planned after assessing alternatives in the Java ecosystem (nothing matched JAI on-demand capabilities required for geospatial content).
  2. LocationTech was able to contact Oracle, resulting in the source code being donated to the Eclipse Foundation as the ImageN project (consider that a $100k savings)
  3. Jody has worked on this project as a background activity when unemployed and the source code now compiles in a modern environment with documentation migrated to markdown (consider that at $25k savings)
  4. However test cases were not provided with the code donation (estimate $25k work remaining)

  Once this library is ready:

  • Migrate JAI-EXT project to ImageN 1.0 baseline (or merge for ImageN 1.1)
  • GeoTools migration to ImageN 1.0 and integration testing

  This activity is suitable for Java developers interested in Image Processing and will require coordination between ImageN, JAI-EXT and GeoTools projects.

  Compiling with Java 17 requires migrating to ImageN library

This roadmap outlines goals that we wish to accomplish - we are seeking resources (funding, developers, testers, documentation writers) before work can be scheduled.

Further reading:

• Jakarta EE
• Replace JAI

Service Providers

Service providers help bring GeoServer technology to a wider audience. We recognize core-contributors who take on an ongoing responsibility for the GeoServer project on our home page, along with a listing of commercial support on our website. We encourage service providers offering GeoServer support to be added to this list.

Helping meet project roadmap planning goals and objectives is a good way for service providers to gain experience with the project and represent their customers in our community. We recognize service providers that contribute to the sustainability of GeoServer as experienced providers.

We encourage service providers to directly take project maintenance and testing activities, and financially support the project if they do not have capacity to participate directly.

Sponsorship Opportunities

The GeoServer project steering committee uses your financial support to fund maintenance activities, code sprints, and research and development that is beyond the reach of an individual contributor.

GeoServer recognizes your financial support on our home page, sponsorship page and in release notes and presentations. GeoServer is part of the Open Source Geospatial Foundation and your financial support of the project is reflected on the OSGeo sponsorship page.

Recommendations:

• Individuals can use Donate via GitHub Sponsors to have their repository badged as supporting OSGeo.
• Individuals who offer GeoServer services should consider $50 USD a month to be listed as a bronze Sponsor on the OSGeo website.
• Organisations using GeoServer are encouraged to sponsor $50 USD a month to be listed as a bronze sponsor on the OSGeo website.
• Organisations that offer GeoServer services should consider $250 a month to be listed as a silver sponsor on the OSGeo website.

For instructions on sponsorship see how to Sponsor via Open Source Geospatial Foundation.

Further reading:

• GeoServer-2024-Sponsorship-Opportunities