Same error stack trace appears multiple times during build

[punktilious]

Is your feature request related to a problem? Please describe. During the build we see several instances of the exception shown below. This is expected, because the invalid configuration is included as part of a unit test. However, recent changes mean that we now hit this error multiple times during the build, whereas before we'd see it only once:

SEVERE: Error while computing search parameters for tenant syntax-error jakarta.json.stream.JsonParsingException: Invalid token=STRING at (line no=3, column no=13, offset=79). Expected tokens are: [COMMA] at org.eclipse.parsson.JsonParserImpl.parsingException(JsonParserImpl.java:449) at org.eclipse.parsson.JsonParserImpl.access$1100(JsonParserImpl.java:54) at org.eclipse.parsson.JsonParserImpl$ObjectContext.getNextEvent(JsonParserImpl.java:503) at org.eclipse.parsson.JsonParserImpl.next(JsonParserImpl.java:375) at org.eclipse.parsson.JsonParserImpl.getObject(JsonParserImpl.java:334) at org.eclipse.parsson.JsonParserImpl.getObject(JsonParserImpl.java:164) at org.eclipse.parsson.JsonReaderImpl.readObject(JsonReaderImpl.java:100) at com.ibm.fhir.config.ConfigurationService.loadConfiguration(ConfigurationService.java:65) at com.ibm.fhir.config.TenantSpecificPropertyGroupCache.createCachedObject(TenantSpecificPropertyGroupCache.java:35) at com.ibm.fhir.config.TenantSpecificPropertyGroupCache.createCachedObject(TenantSpecificPropertyGroupCache.java:20) at com.ibm.fhir.core.TenantSpecificFileBasedCache.getCachedObjectForTenant(TenantSpecificFileBasedCache.java:88) at com.ibm.fhir.config.FHIRConfiguration.loadConfigurationForTenant(FHIRConfiguration.java:231) at com.ibm.fhir.search.parameters.ParametersHelper.buildSearchParameterMaps(ParametersHelper.java:109) at com.ibm.fhir.search.parameters.ParametersHelper.(ParametersHelper.java:77) at com.ibm.fhir.search.util.SearchHelper.(SearchHelper.java:139) at com.ibm.fhir.persistence.jdbc.impl.FHIRPersistenceJDBCImpl.(FHIRPersistenceJDBCImpl.java:315) at com.ibm.fhir.persistence.jdbc.test.spec.R4JDBCExamplesProcessor.process(R4JDBCExamplesProcessor.java:158) at com.ibm.fhir.model.spec.test.R4ExamplesDriver.processExample(R4ExamplesDriver.java:375) at com.ibm.fhir.model.spec.test.R4ExamplesDriver.processExample(R4ExamplesDriver.java:272) at com.ibm.fhir.model.spec.test.R4ExamplesDriver.submitExample(R4ExamplesDriver.java:228) at com.ibm.fhir.model.spec.test.R4ExamplesDriver.processIndex(R4ExamplesDriver.java:126) at com.ibm.fhir.persistence.jdbc.test.spec.R4JDBCExamplesTest.perform(R4JDBCExamplesTest.java:91) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.testng.internal.invokers.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:135) at org.testng.internal.invokers.TestInvoker.invokeMethod(TestInvoker.java:673) at org.testng.internal.invokers.TestInvoker.invokeTestMethod(TestInvoker.java:220) at org.testng.internal.invokers.MethodRunner.runInSequence(MethodRunner.java:50) at org.testng.internal.invokers.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:945) at org.testng.internal.invokers.TestInvoker.invokeTestMethods(TestInvoker.java:193) at org.testng.internal.invokers.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) at org.testng.internal.invokers.TestMethodWorker.run(TestMethodWorker.java:128) at java.base/java.util.ArrayList.forEach(ArrayList.java:1541) at org.testng.TestRunner.privateRun(TestRunner.java:808)

Describe the solution you'd like We should only need to test this bad configuration once. I'd also argue that if we are handling the error, then perhaps we shouldn't be seeing the stack trace anyway.

Describe alternatives you've considered Just ignore the noise.

[lmsurpre]

Ideally, we'd revamp our configuration as part of https://github.com/LinuxForHealth/FHIR/issues/1318

There may be a lighter workaround til then, but we need to be careful here due to threading issues around setting the config home in tests.