Indexing stylesheet: gn-fn-index:json-escape deprecation / regression about core-geonetwork

[fleimgruber]

If someone could give pointers on how to provide more meaningful parsing errors (instead of the cryptic one above) in the GeoNetwork logs e.g. by using some utility in https://github.com/geonetwork/core-geonetwork/tree/main/schemas/iso19115-3.2018 I would be happy to provide a PR for it.

[josegar74]

@fleimgruber I don't think that is related to the deprecation.

That type of errors occur when the xslt function expects a single value and receives more than one.

Not the same error, but a similar issue with other element using concat: #7486

In the previous PR, it happened due to the code assuming 1 element, but it was valid to have several. The xpath expression returned all the values. To fix this kind of errors, usually should be updated with a loop.

Another type of errors, can be for elements with gco:CharacterString, that can be multilingual. If the xpath doesn't contain the gco:CharacterString part, will have issues in a metadata with multilingual values.

In the application server log file (catalina.out for Tomcat), usually there are more details about the line in the indexing file that is failing, so can be identified the code causing the error.

[fleimgruber]

@josegar74 thanks for checking back!

I am running geonetwork in a docker container via https://github.com/geonetwork/docker-geonetwork/tree/main/4.4.1. What is the recommended approach to make such errors visible in the docker container logs?

Edit: Also, the Docker container uses Jetty (not Tomcat) per default and I can't find more info in the Jetty logs. Is there a logging level that could be changed from INFO to DEBUG? Could you give me a pointer into the code where the parsing function is called in Java so that I can test this in an IDE locally?

[fleimgruber]

@josegar74 quick update: I went ahead and tried to reproduce the error locally with a unit test, please see fleimgruber@f7dbda7. I based it off of the 4.4.1 tag.

Analysis: The OP exception from the remote deployment originates at https://github.com/geonetwork/core-geonetwork/blob/4.4.1/core/src/main/java/org/fao/geonet/kernel/search/EsSearchManager.java#L227

so I tried to exercise https://github.com/geonetwork/core-geonetwork/blob/4.4.1/core/src/main/java/org/fao/geonet/kernel/search/EsSearchManager.java#L210

via https://github.com/geonetwork/core-geonetwork/blob/4.4.1/core/src/main/java/org/fao/geonet/kernel/search/EsSearchManager.java#L393

which is the function under test in fleimgruber@f7dbda7. I included the ISO19115 XML file. This test does not reproduce the OP exception, i.e. addMDFields runs fine. I used the "full" IndexingMode, but see the same behaviour with the "core" mode. Am I missing something or do you have a better idea to reproduce the error? For example, is the deployed code maybe trying to parse the XML as ISO19139? Any comments would be much appreciated.

[josegar74]

@fleimgruber

About how to access the server application log in Docker, not sure if docker logs CONTAINERNAME shows that log. Otherwise, you can try this:

docker exec -it CONTAINERNAME bash

And locate the log folder for Jetty and check the console log.

---

The harvester should identify the schema properly, I don't think is identified as ISO19139, otherwise the main branch without #7525 I think would fail also.

I'll check with the file you provide to setup a local folder harvester in my computer to verify it.

[fleimgruber]

Thanks, in #7563 (comment) I was already looking at docker logs and also looked at Jetty logs from within the container both as you mentioned. I could not find more context on the parsing error there, just the OP high level error.

[josegar74]

@fleimgruber I've tested with your metadata with the latest code in the main branch and also with the 4.4.1 tag, using a Local filesystem harvester and I don't get any indexing error.

[fleimgruber]

Thanks for local testing!

Coming back to the logs: I would like to understand more about where in the code the logging happens and to which file to look for more clues of the exact parsing error location. Could you give some pointers here?

Edit: Also related and mentioned in #7563 (comment) can I change the log level to DEBUG to see more context?

[josegar74]

The xslt errors are not logged in the GeoNetwork log file, so it doesn't affect the log level.

The errors are just outputted in the application server console log file. In Jetty, usually it is stored in jetty/logs/output.log.

[fleimgruber]

Ah, I see, thanks for clarification.

This is what I see in the docker container:

jetty@52f612a1cab1:~$ ls -la logs
total 40
drwxr-xr-x 2 jetty jetty 4096 Jan 17 13:15 .
drwxr-xr-x 1 jetty jetty 4096 Jan 17 15:03 ..
-rw-r--r-- 1 jetty jetty 9825 Jan 18 00:00 geonetwork.log
-rw-r--r-- 1 jetty jetty  345 Jan 16 12:26 harvester_default.log
-rw-r--r-- 1 jetty jetty 2473 Jan 17 03:00 harvester_filesystem_test_202401170300.log
-rw-r--r-- 1 jetty jetty 4983 Jan 18 00:00 harvester_webdav_test_202401171315.log

And I can't find an output.log via find / -name output.log 2>/dev/null.

[fleimgruber]

The xslt errors are not logged in the GeoNetwork log file

Thinking about this from a user perspective, how much effort would it be to implement exactly that, so that those errors have the xslt context? E.g. does the exception object carry related data? I would be happy to support a PR for this if you think it's worth it and feasible.

[josegar74]

When you run it from the bundle it has this configuration to create the log file:

core-geonetwork/release/bin/startup.sh

Line 45 in d9c7da5

java $JETTY_CMD > logs/output.log 2>&1 &

But seems that is not in the Docker configuration: https://github.com/geonetwork/docker-geonetwork/blob/a61ee3ee5472c6737e49c5ed3b3a116df459836d/4.4.1/Dockerfile.local#L54C1-L54C4

I would try first the zip bundle from Sourceforge that uses Jetty, to run it locally. That should report the exact error in the Jetty console.

---

About logging the xslt errors, I guess we need to check in https://github.com/geonetwork/core-geonetwork/blob/main/common/src/main/java/org/fao/geonet/utils/Xml.java if it's possible to capture the error output stream and log it in GeoNetwork.

[fleimgruber]

Ad logging xslt errors: Thanks, will look into that.

Ad Jetty console: I changed the docker-entrypoint.sh to contain exec "$@" &> output.log which results in an output.log file, but that file does not contain the xslt errors, only the errors we saw so far already.

Edit: Maybe the assumption is wrong that xslt errors would appear there in this specific case?

[fleimgruber]

@josegar74 I would really like to come up with a reproducible unit test to zoom in on the cause and have a better base for discussion than doing manual deployment tests. I think I made some progress, please see fleimgruber@5bce82c where I use the DataManager to validate the XML and it shows these errors:

XSDValidationErrorEx@129 "XSDValidationErrorEx : XSD Validation error(s):
<xsderrors>
  <error>
    <typeOfError>ERROR</typeOfError>
    <errorNumber>1</errorNumber>
    <message>cvc-complex-type.2.4.a: Invalid content was found starting with element '{"http://standards.iso.org/iso/19115/-3/mdb/2.0":metadataStandard}'. One of '{"http://standards.iso.org/iso/19115/-3/mdb/2.0":metadataIdentifier, "http://standards.iso.org/iso/19115/-3/mdb/2.0":defaultLocale, "http://standards.iso.org/iso/19115/-3/mdb/2.0":parentMetadata, "http://standards.iso.org/iso/19115/-3/mdb/2.0":metadataScope, "http://standards.iso.org/iso/19115/-3/mdb/2.0":contact}' is expected. (Element: mdb:metadataStandard with parent element: mdb:MD_Metadata)</message>
    <xpath>mdb:metadataStandard</xpath>
  </error>
  <error>
    <typeOfError>ERROR</typeOfError>
    <errorNumber>2</errorNumber>
    <message>cvc-complex-type.2.4.a: Invalid content was found starting with element '{"https://schemas.isotc211.org/19115/-3/lan/1.0":PT_Language}'. One of '{"http://standards.iso.org/iso/19115/-3/lan/1.0":PT_Locale}' is expected. (Element: lan:PT_Language with parent element: mdb:defaultLocale)</message>
    <xpath>mdb:defaultLocale/lan:PT_Language</xpath>
  </error>
  <error>
    <typeOfError>ERROR</typeOfError>
    <errorNumber>3</errorNumber>
    <message>cvc-complex-type.2.4.a: Invalid content was found starting with element '{"http://standards.iso.org/iso/19115/-3/cit/2.0":party}'. One of '{"http://standards.iso.org/iso/19115/-3/cit/2.0":role}' is expected. (Element: cit:party with parent element: cit:CI_Responsibility)</message>
    <xpath>mdb:contact/cit:CI_Responsibility/cit:party</xpath>
  </error>
  <error>
    <typeOfError>ERROR</typeOfError>
    <errorNumber>4</errorNumber>
    <message>cvc-complex-type.2.4.a: Invalid content was found starting with element '{"http://standards.iso.org/iso/19115/-3/cit/2.0":CI_DateType}'. One of '{"http://standards.iso.org/iso/19115/-3/cit/2.0":dateType}' is expected. (Element: cit:CI_DateType with parent element: cit:CI_Date)</message>
    <xpath>mdb:identificationInfo/mri:MD_DataIdentification/mri:citation/cit:CI_Citation/cit:date/cit:CI_Date/cit:CI_DateType</xpath>
  </error>
  <error>
    <typeOfError>ERROR</typeOfError>
    <errorNumber>5</errorNumber>
    <message>cvc-complex-type.2.4.a: Invalid content was found starting with element '{"http://standards.iso.org/iso/19115/-3/mri/1.0":status}'. One of '{"http://standards.iso.org/iso/19115/-3/mri/1.0":abstract}' is expected. (Element: mri:status with parent element: mri:MD_DataIdentification)</message>
    <xpath>mdb:identificationInfo/mri:MD_DataIdentification/mri:status</xpath>
  </error>
  <error>
    <typeOfError>ERROR</typeOfError>
    <errorNumber>6</errorNumber>
    <message>cvc-complex-type.2.4.a: Invalid content was found starting with element '{"http://standards.iso.org/iso/19115/-3/cit/2.0":party}'. One of '{"http://standards.iso.org/iso/19115/-3/cit/2.0":role}' is expected. (Element: cit:party with parent element: cit:CI_Responsibility)</message>
    <xpath>mdb:identificationInfo/mri:MD_DataIdentification/mri:resourceMaintenance/mmi:MD_MaintenanceInformation/mmi:contact/cit:CI_Responsibility/cit:party</xpath>
  </error>
</xsderrors>"

Could this be a hint on why the indexing fails or is this just about the schema description?

[josegar74]

The metadata is not valid according to the XSD, but I'm not sure if that is related to the indexing errors, at least as indicated locally I didn't get them.

Can you try with the ZIP bundle? That is running Jetty and you can see the console easier than in the Docker setup.

[fleimgruber]

Can you try with the ZIP bundle?

I tried, but since I am on Windows and the README says the startup.bat requires administrative privileges, I am not able to run it yet as I don't have Java installed for the admin user. Is there a way to run the zip bundle as a regular user?

[josegar74]

I'm not on Windows, but I'm not really sure about that requirement, unless you place the folder in a special Windows folder.

I would try to unzip it to C:\apps\geonetwork or a subfolder inside your home folder and try to start up the application.

[fleimgruber]

Unzipped it into a user folder and looking at #7645

[fleimgruber]

After #7645 (comment) I tried a few values for the Directory Harvester for Windows file paths,

• C:\path\to\sample.xml
• C:/path/to/sample.xml
• ...

which errors because Java interprets it as a network location AFAICS. What should be the value for a Windows file path? I think it would be nice to have that in the docs.

[fleimgruber]

I would like to attach a proper debugger to this, is there an Integration or Unit Test for the Harvester that tests local directory harvesting (skimmed the Harvester*Test.java files)? I could re-use that test infrastructure and figure out questions such as #7563 (comment) myself.

[fleimgruber]

Ok, I think there's progress: The local file system harvesting seems to work now. I mistakenly put a file path as the directory path. With all forward slashes, i.e. C:/Users/LeimgruberF/..., it works.

The WebDAV harvesting (which I use in the Docker deployment) does not work with the local setup:

2024-01-19 16:27:31.089:INFO:oejs.Server:main: Started @19258ms
2024-01-19T16:28:01,560 INFO  [geonetwork.harvester] - Starting harvesting of test
2024-01-19T16:28:01,586 INFO  [geonetwork.harvester] - Started harvesting from node : test (LocalFilesystemHarvester)
2024-01-19T16:28:01,659 INFO  [geonetwork.harvester] - Ended harvesting from node : test (LocalFilesystemHarvester)
2024-01-19T16:28:13,262 INFO  [geonetwork.harvester] - Starting harvesting of test_webdav
2024-01-19T16:28:13,271 INFO  [geonetwork.harvester] - Started harvesting from node : test_webdav (WebDavHarvester)
2024-01-19T16:28:13,272 INFO  [geonetwork.harvester] - WebDav doHarvest start
2024-01-19T16:28:13,515 INFO  [geonetwork.harvester] - Number of remote files found : 1
2024-01-19T16:28:13,515 INFO  [geonetwork.harvester] - Start of alignment for : test_webdav
2024-01-19T16:28:13,526 WARN  [geonetwork.harvester] - Raised exception while harvesting from : test_webdav (WebDavHarvester)
2024-01-19T16:28:13,526 WARN  [geonetwork.harvester] -  (C) Class   : NullPointerException
2024-01-19T16:28:13,527 WARN  [geonetwork.harvester] -  (C) Message : Cannot invoke "String.equals(Object)" because "uri" is null
2024-01-19T16:28:13,527 ERROR [geonetwork.harvester] - Cannot invoke "String.equals(Object)" because "uri" is null
java.lang.NullPointerException: Cannot invoke "String.equals(Object)" because "uri" is null
        at org.fao.geonet.kernel.harvest.harvester.webdav.Harvester.exists(Harvester.java:205) ~[gn-harvesters-4.4.1-0.jar:?]
        at org.fao.geonet.kernel.harvest.harvester.webdav.Harvester.align(Harvester.java:164) ~[gn-harvesters-4.4.1-0.jar:?]
        at org.fao.geonet.kernel.harvest.harvester.webdav.Harvester.harvest(Harvester.java:141) ~[gn-harvesters-4.4.1-0.jar:?]
        at org.fao.geonet.kernel.harvest.harvester.webdav.WebDavHarvester.doHarvest(WebDavHarvester.java:68) ~[gn-harvesters-4.4.1-0.jar:?]
        at org.fao.geonet.kernel.harvest.harvester.AbstractHarvester$HarvestWithIndexProcessor.process(AbstractHarvester.java:554) ~[gn-harvesters-4.4.1-0.jar:?]
        at org.fao.geonet.kernel.harvest.harvester.AbstractHarvester.harvest(AbstractHarvester.java:625) ~[gn-harvesters-4.4.1-0.jar:?]
        at org.fao.geonet.kernel.harvest.harvester.HarvesterJob.execute(HarvesterJob.java:69) ~[gn-harvesters-4.4.1-0.jar:?]
        at org.quartz.core.JobRunShell.run(JobRunShell.java:202) ~[quartz-2.3.2.jar:?]
        at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573) ~[quartz-2.3.2.jar:?]

which I guess is because I have not loaded any metadata standards into that instance yet. If I do so (Admin console > Metadata and Templates), I get these errors:

2024-01-19T16:30:07,492 ERROR [geonetwork.index] - Document with error #2fdc7ad5-3ac9-4394-a6cf-b3014c4787bc: ElasticsearchException[Elasticsearch exception [type=cluster_block_exception, reason=index [gn-records] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];]].
2024-01-19T16:30:07,492 ERROR [geonetwork.index] - {"docType":"metadata","document":"","metadataIdentifier":"2fdc7ad5-3ac9-4394-a6cf-b3014c4787bc","standardNameObject":{"default":"ISO 19115-3 / ISO 19110","langeng":"ISO 19115-3 / ISO 19110"},"indexingDate":"2024-01-19T16:30:07+01:00","mainLanguage":"eng","cl_characterSet":[{"key":"anyValidURI","default":"anyValidURI","langeng":"anyValidURI","link":"http://standards.iso.org/iso/19115/resources/Codelists/cat/codelists.xml#MD_CharacterSetCode"}],"resourceType":["featureCatalog","featureType","featureCatalog"],"contact":[{"organisationObject":{},"role":"pointOfContact","email":"","website":"","logo":"","individual":"","position":"","phone":"","address":""}],"cl_resourceScope":[{"key":"featureType","default":"Feature type","langeng":"Feature type","link":"http://standards.iso.org/iso/19115/resources/Codelists/cat/codelists.xml#MD_ScopeCode"}],"resourceTitleObject":{"default":"Template for feature catalogue","langeng":"Template for feature catalogue"},"featureTypes":[{"typeName":"Table name","definition":"","code":"","isAbstract":"false","aliases":"","attributeTable":[{"name":"Column name","definition":"Definition","code":"","link":"","type":"","cardinality":""}]}],"recordGroup":"2fdc7ad5-3ac9-4394-a6cf-b3014c4787bc","recordOwner":"admin admin","uuid":"2fdc7ad5-3ac9-4394-a6cf-b3014c4787bc","displayOrder":"0","groupPublishedId":"1","popularity":"0","userinfo":"admin|admin|admin|Administrator","groupPublished":"all","isPublishedToAll":"true","record":"record","draft":"n","changeDate":"2024-01-19T15:30:07Z","id":"101","createDate":"2024-01-19T15:30:07Z","isPublishedToIntranet":"false","owner":"1","groupOwner":"1","logo":"/images/logos/5e0fd33a-5c16-4601-a006-9bfbf12dc894.png","hasxlinks":"false","op0":"1","featureOfRecord":"record","isPublishedToGuest":"false","extra":"null","documentStandard":"iso19115-3.2018","op3":"1","valid":"-1","isTemplate":"y","feedbackCount":"0","rating":"0","isHarvested":"false","userSavedCount":"0","sourceCatalogue":"5e0fd33a-5c16-4601-a006-9bfbf12dc894"}
2024-01-19T16:30:07,499 ERROR [geonetwork.index] - Failed to save error documents [2fdc7ad5-3ac9-4394-a6cf-b3014c4787bc].

...

Edit: Figured this out, seems to be an Elasticsearch security setting, freeing some disk space now.

[fleimgruber]

I successfully imported the metadata standards and re-executed the WebDAV harvester, same error as in #7563 (comment), so I would like to contribute a WebDAV test to better debug this - and maybe improve the user facing error message here.

[fleimgruber]

@josegar74 I tried to re-use an existing WebDAV test with our WebDAV URL to debug this more, found a test file that uses AbstractHarvesterIntegrationTest, but found the test method in there ignored:

core-geonetwork/harvesters/src/test/java/org/fao/geonet/kernel/harvest/AbstractHarvesterIntegrationTest.java

Line 68 in 5caefc0

@Ignore(value = "Broken")

I would be happy to update and fix this test, but I am not yet familiar enough with the framework around it, so maybe you could give me some pointers here?

[fleimgruber]

We came up with a test for this, please see fleimgruber@ffe9110 used with a WebDAV serving this XML. It fails at

https://github.com/fleimgruber/core-geonetwork/blob/ffe9110d2cf55ca832e8b14508c3915e762436f8/core/src/main/java/org/fao/geonet/kernel/datamanager/base/BaseMetadataIndexer.java#L367

because fullMd is null.

[fleimgruber]

@josegar74 after using "Admin console > Tools > Delete and create data index" from the web UI of the 4.4.1 zip bundle, I am finally seeing the exact same error in the Jetty logs, but no additional debug information we hoped for.

Error at xsl:value-of on line 1053 of index.xsl:
  XTTE0790: A sequence of more than one item is not allowed as the first argument of
  gn-fn-index:json-escape() ("", "")
2024-01-23T11:52:10,434 ERROR [geonetwork.index] - Indexing stylesheet contains errors: A sequence of more than one item is not allowed as the first argument of gn-fn-index:json-escape() ("", "")
  Marking the metadata as _indexingError=1 in index

If I re-run the harvester after that, I again get from #7563 (comment) java.lang.NullPointerException: Cannot invoke "String.equals(Object)" because "uri" is null

[josegar74]

@fleimgruber is the error occurring with the metadata you provided? I tried it locally and could not reproduce, but I'll check to delete the index, in case that can affect.

[fleimgruber]

Yes, it is with the metadata I provided. But the "uri" error only occurs with the WebDAV harvester - which I wanted to test as the Docker deployment uses that as well.

[fleimgruber]

@josegar74 It turns out the wrong XML file was copied from our test server, so we were testing locally with the wrong file, i.e. sample, and the production server used the problematic file, i.e. full. Note to self: Test all the things and diff all the things.

In summary, please now see in fleimgruber@b64b62c the problematic file in question and a minimal reproducing test case.

; SystemID: jimfs://template/data/config/schema_plugins/iso19115-3.2018/index-fields/index.xsl; Line#: 1053; Column#: -1
net.sf.saxon.trans.XPathException: A sequence of more than one item is not allowed as the first argument of gn-fn-index:json-escape() ("", "") 

I am not too familiar with Java to figure out how to surface a more meaningful error message to the user mentioning the problematic parts of the XML, but I am sure this would be a very helpful feature in general.

FWIW, e.g. comparison and since the VS Code debugger provided this automatically, here is the exact call stack up to where the error occurs.

ApplyTemplates.applyTemplates(SequenceIterator,Mode,ParameterSet,ParameterSet,XPathContextMajor,boolean,int) (\saxon-9.1.0.8b-patch.jar\net.sf.saxon.instruct\ApplyTemplates.class:191)
ApplyTemplates.apply(XPathContext,boolean) (\saxon-9.1.0.8b-patch.jar\net.sf.saxon.instruct\ApplyTemplates.class:138)
ApplyTemplates.processLeavingTail(XPathContext) (\saxon-9.1.0.8b-patch.jar\net.sf.saxon.instruct\ApplyTemplates.class:114)
Block.processLeavingTail(XPathContext) (\saxon-9.1.0.8b-patch.jar\net.sf.saxon.instruct\Block.class:473)
LetExpression.processLeavingTail(XPathContext) (\saxon-9.1.0.8b-patch.jar\net.sf.saxon.expr\LetExpression.class:326)
Block.processLeavingTail(XPathContext) (\saxon-9.1.0.8b-patch.jar\net.sf.saxon.instruct\Block.class:473)
Instruction.process(XPathContext) (\saxon-9.1.0.8b-patch.jar\net.sf.saxon.instruct\Instruction.class:45)
ElementCreator.processLeavingTail(XPathContext) (\saxon-9.1.0.8b-patch.jar\net.sf.saxon.instruct\ElementCreator.class:180)
Block.processLeavingTail(XPathContext) (\saxon-9.1.0.8b-patch.jar\net.sf.saxon.instruct\Block.class:473)
LetExpression.processLeavingTail(XPathContext) (\saxon-9.1.0.8b-patch.jar\net.sf.saxon.expr\LetExpression.class:326)
Template.applyLeavingTail(XPathContext,Rule) (\saxon-9.1.0.8b-patch.jar\net.sf.saxon.instruct\Template.class:91)
ApplyTemplates.applyTemplates(SequenceIterator,Mode,ParameterSet,ParameterSet,XPathContextMajor,boolean,int) (\saxon-9.1.0.8b-patch.jar\net.sf.saxon.instruct\ApplyTemplates.class:218)
ApplyTemplates$ApplyTemplatesPackage.processLeavingTail() (\saxon-9.1.0.8b-patch.jar\net.sf.saxon.instruct\ApplyTemplates.class:527)
Controller.transformDocument(NodeInfo,Result) (\saxon-9.1.0.8b-patch.jar\net.sf.saxon\Controller.class:967)
Controller.transform(Source,Result) (\saxon-9.1.0.8b-patch.jar\net.sf.saxon\Controller.class:833)
Xml.transform(Element,Path,Result,Map) (c:\Users\LeimgruberF\dev\core-geonetwork\common\src\main\java\org\fao\geonet\utils\Xml.java:525)
Xml.transform(Element,Path,Map) (c:\Users\LeimgruberF\dev\core-geonetwork\common\src\main\java\org\fao\geonet\utils\Xml.java:395)
EsSearchManager.addMDFields(Element,Path,Element,MetadataType,IndexingMode) (c:\Users\LeimgruberF\dev\core-geonetwork\core\src\main\java\org\fao\geonet\kernel\search\EsSearchManager.java:218)
EsSearchManager.index(Path,Element,String,Multimap,MetadataType,boolean,IndexingMode) (c:\Users\LeimgruberF\dev\core-geonetwork\core\src\main\java\org\fao\geonet\kernel\search\EsSearchManager.java:401)
BaseMetadataIndexer.indexMetadata(String,boolean,IndexingMode) (c:\Users\LeimgruberF\dev\core-geonetwork\core\src\main\java\org\fao\geonet\kernel\datamanager\base\BaseMetadataIndexer.java:560)

[fleimgruber]

@josegar74 I added a Minimal Reproducing Example with respect to XML data in fleimgruber@58341e2.

I also figured out the cause of this issue from the hint "index.xsl; Line#: 1053". It turns out that the problem was that the XML did not match the description in

core-geonetwork/schemas/iso19115-3.2018/src/main/plugin/iso19115-3.2018/index-fields/index.xsl

Line 1005 in df6a770

"typeName" : "<xsl:value-of select="util:escapeForJson(gfc:FC_FeatureType/gfc:typeName/text())"/>",

i.e. typeName must be scalar as in:

<gfc:typeName>service__sample_layer</gfc:typeName>

I still think the user experience would be much better if the error would explicitly mention the invalid parts. If the variable reference $jsonFeatureTypes in index.xsl could be avoided, then the real cause (typeName) might bubble up?

Aside from that, a lot of time would have been saved if the "index.xsl; Line#: 1053;" part would have shown up in the Jetty server logs from the start, as mentioned in #7563 (comment).

@fxprunayre because the git log shows that you contributed to this file as well.