Support service metadata files in subdirectories #303
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Consider a deegree INSPIRE workspace with several WMS and WFS instances:
In the use-cas, it is important to have separate services for each inspire theme. For WMS, the GetCapabilities request returns a document with the data from the correct wms_metadata.xml. The problem is that for WFS it does not seem to use the wfs_metadata.xml from the corresponding directory. The WFS GetCapabilities document contains some default values for metadata.
Currently, when a wfs_metadata.xml is put in the directory workspaces/inspire/services/, that file is picked up by both AD and CP WFS capabilities. This patch fixes that behavior.
Note that a patch for 3.4 is not required, as this already works as expected. This is an effect of the workspace reimplementation.