|
I am trying to automate the process of deploying my GeoServer by using a script that takes advantage of the REST interface to configure the workspaces, datastores, etc, which is working fairly well at this point. I recently ran into a need to configure the netcdf-out plugin. If I GET /rest/settings, I get the following relevant portion:
{'global':
{'settings':
{'charset': 'utf-8',
'contact': { ... snip ... },
'id': 'SettingsInfoImpl-639a7ad2:17822c9dc27:-8000',
'localWorkspaceIncludesPrefix': False,
'metadata': {'map': [{'entry': {'netCDFSettings': {'compressionLevel': 0,
'copyAttributes': False,
'copyGlobalAttributes': False,
'dataPacking': 'NONE',
'shuffle': True},
'string': 'NetCDFOutput.Key' }} ]},
'numDecimals': 0,
'showCreatedTimeColumnsInAdminList': False,
'showModifiedTimeColumnsInAdminList': False,
'verbose': False,
'verboseExceptions': False},
... snip ...
}
}
These are mostly perfectly normal default settings from a stock install of geoserver and the netcdf-out plugin (along with the native C netcdf libraries being loaded). As an experiment, I tried round-tripping the settings back through PUT /rest/settings. I get a response code of 500 and the response text is:
---- Debugging information ----
cause-exception : java.lang.ClassCastException
cause-message : class org.geoserver.web.netcdf.NetCDFSettingsContainer cannot be cast to class java.lang.String (org.geoserver.web.netcdf.NetCDFSettingsContainer is in unnamed module of loader org.apache.catalina.loader.ParallelWebappClassLoader @14ceb7e1; java.lang.String is in module java.base of loader 'bootstrap')
class : org.geoserver.catalog.MetadataMap
required-type : org.geoserver.catalog.MetadataMap
converter-type : org.geoserver.config.util.XStreamPersister$SettingsTolerantMapConverter
line number : -1
class[1] : org.geoserver.config.impl.SettingsInfoImpl
required-type[1] : org.geoserver.config.impl.SettingsInfoImpl
converter-type[1] : org.geoserver.config.util.XStreamPersister$SettingsInfoConverter
class[2] : org.geoserver.config.impl.GeoServerInfoImpl
required-type[2] : org.geoserver.config.impl.GeoServerInfoImpl
converter-type[2] : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
version : 2.17.2
-------------------------------
So, it looks like some sort of serialization bug, I am guessing (I am a python programmer, not a java programmer, so I am groping in the dark here).
I did some digging through the geoserver codebase, and I found several tests that utilizes netCDFSettings as an invalid case (src/main/src/test/java/org/geoserver/config/util/XStreamPersisterTest.java), but no indication as to why they are invalid. The values used in those cases seems to correspond to the values in the given mapping – which are the defaults presented by geoserver itself! I could not find a single test that actually demonstrated a nominal round-trip of the netCDFSettings container through persistence.
This inability to set the netCDFSettings metadata actually becomes a roadblock in setting other things in settings, because if you don’t set anything for metadata in the REST PUT call, then that section of the settings gets clobbered. So, if I just wanted to set the contact information, I can’t ignore metadata or else it’ll get clobbered. But if I supply metadata, even with the default values, I get an error.
|
Medium
