Elasticsearch community plugin fails to load on GeoServer 3.0.x due to missing HttpClient 4 library

GeoServer GeoServer User
,
1

I installed the Elasticsearch community plugin from:

geoserver-3.0.0-SNAPSHOT-elasticsearch-plugin.zip

When using the plugin with GeoServer 3.0.0 or 3.0.1, the following warning is logged during startup:

WARN --- org.geotools.util.logging.Log4J2Logger:184: Can't load a service for category "DataStoreFactorySpi". Cause is "ServiceConfigurationError: org.geotools.api.data.DataStoreFactorySpi: org.geotools.data.elasticsearch.ElasticDataStoreFactory Unable to get public no-arg constructor".

This is not only a warning: the Elasticsearch data store is not available in GeoServer.

Analysis

The problem appears to be that httpclient-4.5.14.jar, which is required by the GeoTools ElasticDataStoreFactory, is missing from the plugin package.

The Elasticsearch plugin assembly descriptor contains the following entries:

<include>httpcore-nio*</include>
<include>httpasyncclient*</include>
<include>httpcore-nio*</include>

httpcore-nio is included twice, while httpclient is not included. This appears to be a copy-and-paste error.

In GeoServer versions before 3.0.x, httpclient-4.5.14.jar was already included in the main GeoServer distribution. Its absence from the Elasticsearch plugin package therefore did not cause a problem.

GeoServer 3.0.x now uses Apache HttpClient 5. The legacy httpclient-4.5.14.jar is consequently no longer present in WEB-INF/lib. However, the Elasticsearch data store still uses HttpClient 4 classes under the org.apache.http.* packages. HttpClient 5 cannot provide these classes because it uses the org.apache.hc.* packages.

Confirmed workaround

Copying httpclient-4.5.14.jar into GeoServer’s WEB-INF/lib directory and restarting GeoServer resolves the problem. The Elasticsearch data store then becomes available.

HttpClient 4 and HttpClient 5 can coexist because they use different Java package names.

Proposed fix

The plugin assembly could package the required HttpClient 4 library by replacing the duplicated httpcore-nio entry:

 <include>httpcore-nio*</include>
 <include>httpasyncclient*</include>
-<include>httpcore-nio*</include>
+<include>httpclient-4*</include>

Would this be the appropriate fix for the Elasticsearch community plugin assembly on the GeoServer 3.0.x branch?

2

Good troubleshooting!

A couple questions:

  • Q: Can the datastore migrate to http-client 5 for compatibility with the rest of geoserver?
    A: Not sure perhaps you could check?
  • Q: Is there any conflict between using http-client-5 and http-client-4 at the same time?
    A: No you note that they can coexisting because of use of different class names

And an invitation:

  • Please make a pull request to update the assembly descriptor!

Community modules are considered under development are not subject to the usual QA checks and balances until the author is ready to put forward for consideration as an extension.

3

Thanks for your quick response.

Regarding your question:

  • Q: Can the datastore be migrated to http-client 5 for compatibility with the rest of GeoServer?
    A: The datastore is part of GisTools and should be updated there. At the moment, I cannot verify this.

I’ve created a pull request and linked this topic there: Fix Elasticsearch community plugin fails to load on GeoServer 3.0.x by geozap · Pull Request #9844 · geoserver/geoserver · GitHub

Unfortunately, the build job for the request failed: Fix Elasticsearch community plugin fails to load on GeoServer 3.0.x · geoserver/geoserver@d33ffce · GitHub

I’m not sure if this is related to my commit and what the next steps should be.

By the way, I think the pull request could also be backported to GeoServer 3.0.x.