Since 2.17.3 JTS has been upgraded to 1.17.0
JTS 1.17 breaks API compatibility (see https://github.com/locationtech/jts/blob/master/doc/JTS_Version_History.md#api-changes-1)
This break happens within the postgis driver for hibernate spatial 1.1.3.1 used by GeoFence.
This means that if GeoFence runs as a standalone webapp, the JTS version will be the one declared within the GeoFence deps and everything will work. When GeoFence is run within GeoServer, it will use the GeoServer version, and hibernate spatial will break.
A new version of hibernate spatial (1.1.3.2) has been built with support to JTS 1.17.
Since GeoServer 2.17.x relies on GeoFence 2.4.6, a new release (2.4.6.1) has been done, using the updated hibernate-spatial version.
Version 2.18 will use the 3.4.6 as well, since next version brings in some changes in DTOs (SRID and areas)
Version 2.19 is using a geofence version that supports the SRID and area changes.
Pls also refer to https://github.com/geoserver/geofence/issues/166
GeoServer >=2.17.3
geofence-server with postgis backend
are you actively working this (e.g. submitting a PR to hibernate)? Either way, let me know if I can help.
yes, working on this. Fact is, the hibernate spatial used in this project is really old, and I hardly managed to retrieve the old code from sources jar files. I put the sources back into this repo .
Pls note that there is no code change involved, only a rebuild with the correct jts version is needed.
Great, thanks!
Idly, I wonder if it’d be possible to migrate GeoFence to some other alternative. (Admittedly, that may involve a fair bit of work.)
Do you mean to migrate from hibernate-spatial, or from hibernate?
Since GeoFence does not use the spatial capabilities of hibspatial, except for the storing of Geometry objects, it’s an option we were evaluating.