Thanks for testing with several versions. I just put out as request to test with nightly build ahead of release next week.
- I do not see any class called “org.apache.httpclient.URIUtil” in the http client jar.
- I cannot see GeoServer code calling “org.apache.httpclient.URIUtil”
- I cannot see any GeoTools code calling “org.apache.httpclient.URIUtil”
So we need to find the stack trace from the logs. You supplied a screen snap - but I need to see the “caused by” information a bit further down. Something is odd …
test setup
- Using your example to test the latest:
docker run -it -p8080:8080 \
--env INSTALL_EXTENSIONS=true \
--env STABLE_EXTENSIONS="importer" \
--env CORS_ENABLED=true \
docker.osgeo.org/geoserver:2.26.x
-
We need an example that works with the default data directory.
Working from Importer REST API examples — GeoServer 2.26.x User Manual
-
Adjust import.json so we reference a local folder:
{
"import": {
"targetWorkspace": {
"workspace": {
"name": "ne"
}
},
"data": {
"type": "directory",
"location": "/opt/geoserver_data/data/shapefiles"
}
}
}
- Adapting the exaple:
curl -v -u admin:geoserver -XPOST -H "Content-type: application/json" \
-H "Accept: application/json" \
-d @import.json \
"http://localhost:8080/geoserver/rest/imports"
- And I get something …
...
< HTTP/1.1 201
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Location: http://localhost:8080/geoserver/rest/imports/2
< Content-Type: application/json
< Transfer-Encoding: chunked
< Date: Tue, 10 Sep 2024 02:52:21 GMT
<
* Connection #0 to host localhost left intact
{"import":{"id":2,"href":"http://localhost:8080/geoserver/rest/imports/2","state":"PENDING","archive":false,"targetWorkspace":{"workspace":{"name":"ne","isolated":false,"dateCreated":"2022-08-21 15:10:28.234 UTC","dateModified":"2022-09-23 08:29:42.450 UTC"}},"data":{"type":"directory","format":"Shapefile","location":"/opt/geoserver_data/data/shapefiles","href":"http://localhost:8080/geoserver/rest/imports/2/data"},"tasks":[{"id":0,"href":"http://localhost:8080/geoserver/rest/imports/2/tasks/0","state":"READY"}]}}
- And I can see in the GUI that the import was created
reproducing your test
Your example listed “remote” which is intended to like download from a URL location … so it makes sense it would use http client. However your example listed file.shz - which is like a local file?
Trying it out on a public shape file download: https://www.naturalearthdata.com/
https://naciscdn.org/naturalearth/110m/cultural/ne_110m_admin_0_countries.zip
{
"import": {
"targetWorkspace": {
"workspace": {
"name": "ne"
}
},
"data": {
"type": "remote",
"location": "/Users/jgarnett/Downloads/ne_110m_admin_0_countries.zip"
}
}
}
And I can finally see your error:
* upload completely sent off: 233 bytes
< HTTP/1.1 500
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Content-Type: text/plain
< Transfer-Encoding: chunked
< Date: Tue, 10 Sep 2024 02:59:18 GMT
< Connection: close
<
* Closing connection
Handler dispatch failed; nested exception is java.lang.NoClassDefFoundError: org/apache/commons/httpclient/util/URIUtil
And the stack trace:
Caused by: java.lang.NoClassDefFoundError: org/apache/commons/httpclient/util/URIUtil
at org.apache.commons.vfs2.provider.URLFileName.getPathQueryEncoded(URLFileName.java:91)
at org.apache.commons.vfs2.provider.URLFileName.getURIEncoded(URLFileName.java:161)
at org.apache.commons.vfs2.provider.url.UrlFileObject.createURL(UrlFileObject.java:74)
at org.apache.commons.vfs2.provider.url.UrlFileObject.doAttach(UrlFileObject.java:63)
at org.apache.commons.vfs2.provider.AbstractFileObject.attach(AbstractFileObject.java:1505)
at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:489)
at org.apache.commons.vfs2.provider.AbstractFileObject.exists(AbstractFileObject.java:477)
at org.apache.commons.vfs2.provider.AbstractFileObject.copyFrom(AbstractFileObject.java:1013)
at org.geoserver.importer.Directory.accept(Directory.java:395)
...
Caused by: java.lang.ClassNotFoundException: org.apache.commons.httpclient.util.URIUtil
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1308)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1120)
found
So I think we have enough for a bug report … [GEOS-11533] - JIRA
- The “virtual file system” thing, vfs2, seems to not be compatible with this version of httpclient?
- Checking Commons VFS – Project Dependencies
- Shows that this version 2.9.1 is compatible with httpclient 3.1 used by GeoServer
update: I was wrong “remote” does not seem to take a remote URL (https://naciscdn.org/naturalearth/110m/cultural/ne_110m_admin_0_countries.zip). It was previously used with the community module “REST resumable upload” to stage the data, and then import.
Whew!
