search

geonetwork / core-geonetwork

GeoNetwork is a catalog application to manage spatially referenced resources. It provides powerful metadata editing and search functions as well as an interactive web map viewer. It is currently used in numerous Spatial Data Infrastructure initiatives across the world.
http://geonetwork-opensource.org/
GNU General Public License v2.0
423 stars 489 forks source link

Indexing stylesheet: gn-fn-index:json-escape deprecation / regression #7563

Open fleimgruber opened 10 months ago

fleimgruber commented 10 months ago

Describe the bug Harvesting file system XML leads to indexing error that does not occur with the same XML on v4.2.x

To Reproduce File system harvester with given XML file.

Expected behavior Indexing succeeds as in stable version.

Screenshots

Log file

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

Desktop (please complete the following information):

Additional context I had a look into the offending function json-escape and found a deprecation comment so I first want to make sure that the issue is not about deprecation and leftover usage of that function during deprecation work. In case this is expected to work, I will experiment more with a reduced XML that still triggers the error.

Edit: For experimenting with reduced XML, I looked for repo tests to hook into. Is core-geonetwork\web\src\test\java\org\fao\geonet\xslt\common\ValidateSupportedEmailXslTest.java the correct place to look into as a test template?

fleimgruber commented 9 months ago

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 commented 9 months ago

@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: https://github.com/geonetwork/core-geonetwork/pull/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 commented 9 months ago

@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 commented 9 months ago

@josegar74 quick update: I went ahead and tried to reproduce the error locally with a unit test, please see https://github.com/fleimgruber/core-geonetwork/commit/f7dbda7032f1017719c7547b569a1c881e33520c. 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 https://github.com/fleimgruber/core-geonetwork/commit/f7dbda7032f1017719c7547b569a1c881e33520c. 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 commented 9 months ago

@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 https://github.com/geonetwork/core-geonetwork/pull/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 commented 9 months ago

Thanks, in https://github.com/geonetwork/core-geonetwork/issues/7563#issuecomment-1895748585 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 commented 9 months ago

@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 commented 9 months ago

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 https://github.com/geonetwork/core-geonetwork/issues/7563#issuecomment-1895748585 can I change the log level to DEBUG to see more context?

josegar74 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

When you run it from the bundle it has this configuration to create the log file: https://github.com/geonetwork/core-geonetwork/blob/d9c7da56869b4410900e3be6eb359e9f286b12a1/release/bin/startup.sh#L45

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 commented 9 months ago

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 commented 9 months ago

@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 https://github.com/fleimgruber/core-geonetwork/commit/5bce82c0c1f24ad2a1075ebc4091a9a1ff61958c 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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

Unzipped it into a user folder and looking at https://github.com/geonetwork/core-geonetwork/issues/7645

fleimgruber commented 9 months ago

After https://github.com/geonetwork/core-geonetwork/issues/7645#issuecomment-1900559358 I tried a few values for the Directory Harvester for Windows file paths,

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 commented 9 months ago

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 https://github.com/geonetwork/core-geonetwork/issues/7563#issuecomment-1900565416 myself.

fleimgruber commented 9 months ago

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 commented 9 months ago

I successfully imported the metadata standards and re-executed the WebDAV harvester, same error as in https://github.com/geonetwork/core-geonetwork/issues/7563#issuecomment-1900638503, so I would like to contribute a WebDAV test to better debug this - and maybe improve the user facing error message here.

fleimgruber commented 9 months ago

@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:

https://github.com/geonetwork/core-geonetwork/blob/5caefc00d3afa3e355eb1e8d391aa85d59b733fc/harvesters/src/test/java/org/fao/geonet/kernel/harvest/AbstractHarvesterIntegrationTest.java#L68

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 commented 9 months ago

We came up with a test for this, please see https://github.com/fleimgruber/core-geonetwork/commit/ffe9110d2cf55ca832e8b14508c3915e762436f8 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 commented 9 months ago

@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 https://github.com/geonetwork/core-geonetwork/issues/7563#issuecomment-1900638503 java.lang.NullPointerException: Cannot invoke "String.equals(Object)" because "uri" is null

josegar74 commented 9 months ago

@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 commented 9 months ago

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 commented 9 months ago

@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 https://github.com/fleimgruber/core-geonetwork/commit/b64b62c6cb5f2fdcbf103dde900e50dc2db7b486 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 commented 8 months ago

@josegar74 I added a Minimal Reproducing Example with respect to XML data in https://github.com/fleimgruber/core-geonetwork/commit/58341e24f9e6356b087aeba904cd95b85ea09d19.

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 https://github.com/geonetwork/core-geonetwork/blob/df6a7708d404c3bae9cdef198eb0973633221bb0/schemas/iso19115-3.2018/src/main/plugin/iso19115-3.2018/index-fields/index.xsl#L1005

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 https://github.com/geonetwork/core-geonetwork/issues/7563#issuecomment-1881375338.

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