Initialization of resource '*' failed

[JoKord]

Hello.

Im am using Deegree3 version 3.4.11 and today for a reason I cannot explain all my SQLFeatureStores started are giving the following error:

Initialization of resource 'Appurtenance_Avenca' failed: Unable to build resource FeatureStoreProvider:Appurtenance_Avenca: Error building GML application schema: Severe error in schema document (systemId: null, line: -1, column: -1) Premature end of file.

I haven't changed anything in my FeatureStores and yesterday was working fine.
Is anyone else experiencing the same issues?
It might be a broken link problem.

Kind Regards,

[lgoltz]

We also had some troubles tonight. It seems that some external schema files were not available.

[JoKord]

Might it be related with Deegree3 external schema files or INSPIRE directive external schema files?

[ettweina]

We have the same problems with SQLFeatureStores but on top with the LayerStoreProvider.
[10:19:58] ERROR: [DefaultWorkspace] Unable to build resource LayerStoreProvider:ps_fgeo_waldschutz: Dependent resource FeatureStoreProvider:ps_fgeo_waldschutz failed to initialize.
So I'am not really sure that the error comes from the schema.
We tested an SQLFeatureStore where we host the INSPIRESchemaFiles locally. Same error.

[mattenp]

Yes, I have the same problem...
A workaround is to use all schema imports in xml-schema offline, also gml and gmd-schema
then you have to change the schemaLocation in your INSPIRE-appschema

f. e. ElevationVectorElements.xsd
<import namespace="http://inspire.ec.europa.eu/schemas/base/3.3" schemaLocation="BaseTypes.xsd"/> <import namespace="http://inspire.ec.europa.eu/schemas/el-bas/4.0" schemaLocation="ElevationBaseTypes.xsd"/> <import namespace="http://inspire.ec.europa.eu/schemas/gn/4.0" schemaLocation="GeographicalNames.xsd"/> <import namespace="http://inspire.ec.europa.eu/schemas/hy-p/4.0" schemaLocation="HydroPhysicalWaters.xsd"/> <import namespace="http://www.isotc211.org/2005/gmd" schemaLocation="../gmd/gmd.xsd"/> <import namespace="http://www.opengis.net/gml/3.2" schemaLocation="../gml/gml.xsd"/>

I download schema-files this way:

`# gml 3.2.1
schema=http://schemas.opengis.net/gml/3.2.1/
schema_directory=gml
wget --no-check-certificate -e use_proxy=yes -e https_proxy=proxyhost:proxyPort $schema
egrep -o "href="[%0-9a-zA-Z_-.()]*xml|href="[%0-9a-zA-Z_-.()]*xsd" index.html | sed 's/href="//' > files.txt

for i in cat files.txt; do wget --no-check-certificate -e use_proxy=yes -e https_proxy=proxyhost:proxyPort "$schema/$i" -P ./inspire_offline/$schema_directory; done
rm index.html files.txt`

[JoKord]

Is there no other way to solve the problem without having an offline xml-schema?
And by the way if that is the problem then how can I download if the links for the schema are wrong and not working for deegree?
I guess I'm not fully understanding the problem here.

Shouldn't the link http://www.deegree.org/datasource/feature/sql/ be returning something other than 404?

[stempler]

If the problem is related to INSPIRE schemas the issue could be that they are now no longer available directly via http://, there now is a redirect to https://. If that's the issue here, then whatever is loading the schema can't handle the redirect. Even changing the schema URL to use https may not help, as some INSPIRE schemas reference other INSPIRE schemas in the schema files, using the http address.

[ettweina]

Yes, that's exactly the problem.
If we change the URLs for the INSPIRE schemas (only possible in INSPIRE schemas which has no mor schemas included or to import) from http to https deegree can receive the schemas and the services can be build.
deegree cannot handle the automatic redirection to HTTPS of the INSPIRE reverse proxy.
I've found this on the INSPIRE homepage. There is only mentioned the registry, but I suppose that the schemas are affected as well.
'In order to comply with the rules provided by our ICT Governance, we need to force the HTTPS protocol on the central INSPIRE registry service from 31 March. This means that all HTTP requests will be automatically redirected to HTTPS. The reference to items in the registry will still be implemented using HTTP URIs. Our reverse proxy will take care of the automatic redirection to HTTPS. If you have tools or applications accessing the registry, please make sure that they are capable of handling such redirects correctly.'

[ettweina]

Alexander Dömming from GDI-DE made the following proposal:
XML-catalog (https://en.wikipedia.org/wiki/XML_catalog)
The XML catalog is a document describing a mapping between external entity references and locally cached equivalents. But perhaps it can also be used to map the http INSPIRE Urls to https URLs until deegree ist able to manage the redirect.
Is it possible to use XML-Catalog with deegree?
And if yes, how can I implement it?

[tfr42]

@ettweina I am not aware if the XML-Catalog applies for XSD schema files too. The class responsible for resolving external files is

deegree3/deegree-core/deegree-core-commons/src/main/java/org/deegree/commons/xml/schema/RedirectingEntityResolver.java

Line 83 in 51cdd20

public String redirect( String systemId ) {

The implementation is using the Apache Xerxes 2.12.0 API.

This may be a good starting point to apply a patch.

The TMC will discuss this issue in the next TMC meeting, scheduled for Friday 2020-05-22.

[mattenp]

Mail to JRC:

since yesterday we can no longer use the INSPIRE application schemes online. I suppose it has to do with the HTTPS switchover (see #1064 https://urldefense.com/v3/__https://github.com/deegree/deegree3/issues/1064__;!!DOxrgLBm!XmZsEjW0bhDCmb9IeetrAk8BhVzm612qT046tEE9rGtJOOHmYVbnudiFtppZ_tgJDbqd15AS1WgyJA$ and https://inspire.ec.europa.eu/news/inspire-re3gistry-software-and-inspire-registry-service-update ).

answer from JRC-INSPIRE-SUPPORT@ec.europa.eu

Thank you for your feedback. We have now restored the access to the schemas through http. Sorry for the inconvenience.

[tfr42]

The TMC members conclude that the issue reported was caused by a change of the server setup providing the INSPIRE schema files. Nevertheless deegree shall support a properly configured server-sided redirect and retrieve external resources using HTTPS. This needs to be tested. To extend deegree to use bundled local files instead of remote resources we have created a new issue #1066.
The TMC kindly asks JRC to keep us in the loop when changes of this magnitude are planned in the future.

[tfr42]

Switch to HTTPS is planned for March 2021, see https://wiki.gdi-de.org/display/insp/2021/02/01/INSPIRE-Schemata+werden+von+HTTP+nach+HTTPS+migriert (German only)

[tfr42]

Users have reported issues starting and reloading deegree workspace with references to INSPIRE schema files after 1st of March.

[tfr42]

A temporary workaround is to use https instead of http in all local files that reference INSPIRE schema files, e.g .:

<import namespace = "http://inspire.ec.europa.eu/schemas/base/3.3" schemaLocation = "https://inspire.ec.europa.eu/schemas/base/3.3/BaseTypes.xsd" />

Important: "https" only for the attribute "schemaLocation", not for the "namespace"!

Or download all INSPIRE schema files from the JRC server at https://inspire.ec.europa.eu/schemas/ and adapt them so that all references are resolved locally, e.g.

<import namespace = "http://inspire.ec.europa.eu/schemas/base/3.3" schemaLocation = "../ base / 3.3 / BaseTypes.xsd" />

However, we see the need for deegree to be able to handle this protocol change. We are currently working on a pull request to resolve this issue.

[tfr42]

Bugfix version 3.4.16 contains the PR #1131. Download via GitHub and www.deegree.org available soon.

[tfr42]

Bug fix version ready to download from https://github.com/deegree/deegree3/releases and https://www.deegree.org/download/.