Pierre Mauduit created an issue |
gs-flatgeobuf extension can clash with “directory of shapefiles” datastores |
Issue Type: |
Bug |
---|---|
Affects Versions: |
2.20.4 |
Assignee: |
Unassigned |
Created: |
13/Jan/23 2:07 PM |
Environment: |
Encountered on a geOrchestra geoserver 2.20.4, including gs-flatgeobuf extension, but this may affect more recent versions as well.
|
Priority: |
Medium |
Reporter: |
This issue has been reported on the geoserver-devel mailing-list: When using a GeoServer along with the gs-flatgeobuf extension, the gt-flatgeobuf comes naturally as a dependency, and this might cause issues with datastores, because GeoServer could select the wrong factory to manage said datastores. From our understanding this following call to There are no ordering in the collection being returned, and canProcess() methods from both factories will return true with the given params hashmap:
So depending on the order, we can end up with a “directory of shapefiles” datastore which would be handled by a FlatGeobufDatastoreFactory, resulting in every underlying layers fail. One workaround from our side had been to remove the flatgeobuf extension (incl. the gt-flatgeobuf jar from the webapp’s classpath), as the format was actually not needed/not in use in our environment. |
Get Jira notifications on your phone! Download the Jira Cloud app for Android or iOS |
|
This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100214-sha1:b03f6a4) |