Open tfr42 opened 3 years ago
While using/testing of deegree version 3.5.8 and 3.6.0-pre2, it was observed that the bug does not appear anymore when editing resources through the deegree webconsole.
Nevertheless, the bug still appears under usage of the deegree REST API. For example with the following request when using the deegree-utah-workspace:
http://localhost:8080/deegree-webservices/config/restart/datasources/feature/utah_airports
Response:
Restart of workspace deegree-workspace-utah completed. Restarted resources:
- utah_airports
- layer_feature_utah_airports
- wfs
- wfs110
- theme_wms
- wms
In the deegree webconsole the listed resources are then deactivated (or dropped) while maintaining their functionality (visual bug) and cannot be activated again:
Note: The deegree-utah-workspace WFS configuration needs to be adjusted (entering a specific FeatureStoreId) in order to use the provided request.
When editing a resource using the admin console only the resource itself and all its dependents remain. Resources sharing one of the resource dependents are removed from the view. The resources still exist in the file system but are not shown in the console. Example: When WMS and WFS service configuration use the same FeatureStore configuration and the WFS is edited, the WMS related resources are dropped. The deegree REST API is also affected, for requests such as /config/restart/[path_to_resource]
Current workaround is to reload the complete workspace.
All versions since 3.4.0 are affected.