Upgrade dependencies for v1.17.x

[dennisvang]

Upgrade dependencies to match current develop branch:

• upgraded JDK from 17 to 21
• upgraded various dependencies in pom.xml
• removed redundant spring-data-mongodb version pin to fix conflict
• adapted deprecated references in JwtService class to match develop

[dennisvang]

Spent a few hours trying to figure out why tests were failing... Turns out this is due to the fact that the spring-data-mongodb version is pinned in the pom.xml, whereas this version should actually be managed by the spring-boot-starter-parent (see list of spring boot managed dependencies):

FAIRDataPoint/pom.xml

Lines 193 to 195 in 34fb697

	<groupId>org.springframework.data</groupId>
	<artifactId>spring-data-mongodb</artifactId>
	<version>${mongodb.spring-data.version}</version>

This resulted in a (silent) version conflict, leading to obscure errors like:

2025-05-20 17:59:04,218 2573 [main] ERROR org.springframework.boot.SpringApplication - Application run failed
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'configController': Unsatisfied dependency expressed through field 'configService': Error creating bean with name 'configService': Unsatisfied dependency expressed through field 'resourceDefinitionService': Error creating bean with name 'resourceDefinitionService': Unsatisfied dependency expressed through field 'targetClassesCache': Error creating bean with name 'resourceDefinitionTargetClassesCache': Invocation of init method failed

Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'configService': Unsatisfied dependency expressed through field 'resourceDefinitionService': Error creating bean with name 'resourceDefinitionService': Unsatisfied dependency expressed through field 'targetClassesCache': Error creating bean with name 'resourceDefinitionTargetClassesCache': Invocation of init method failed

Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'resourceDefinitionService': Unsatisfied dependency expressed through field 'targetClassesCache': Error creating bean with name 'resourceDefinitionTargetClassesCache': Invocation of init method failed

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'resourceDefinitionTargetClassesCache': Invocation of init method failed

Caused by: java.lang.ClassCastException: class org.springframework.data.repository.query.DefaultParameters cannot be cast to class org.springframework.data.mongodb.repository.query.MongoParameters (org.springframework.data.repository.query.DefaultParameters and org.springframework.data.mongodb.repository.query.MongoParameters are in unnamed module of loader 'app')

[dennisvang]

Tests Import_POST.res403_noToken and Import_POST.res403_nonAdminToken started failing after this dependency upgrade, returning status 400 instead of expected 403, without related code changes.

In addition, Import_POST.res200_* tests started erroring as follows

Import_POST.res200_singleImport:138 » RestClient Error while extracting response for type 
  [java.util.List<nl.dtls.fairdatapoint.api.dto.schema.MetadataSchemaVersionDTO>] 
  and content type [application/json]
...
Caused by: com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot deserialize value of type
  `java.util.ArrayList<nl.dtls.fairdatapoint.api.dto.schema.MetadataSchemaVersionDTO>` 
  from Object value (token `JsonToken.START_OBJECT`)

I traced this down to the change from spring-boot-starter-parent 3.1.x to 3.2.x or later (current 3.4.5).

Now to come up with a fix.

Side note: for the no-token cases, shouldn't a status 401 be returned instead of 403?

debugging notes:

• starter 3.1.1 does not work with jdk 21, but 3.1.12 does
• springdoc version depends on starter version, see here, e.g. 2.2.0 for starter 3.1.12, 2.3.0-2.5.0 for starter 3.2.12
• httpclient5 should be 5.2.1 for older starters

[dennisvang]

Apparently spring-security's method-level security annotations (@PreAuthorize) are executed after request body validation (@Valid).

To me this makes no sense at all, but, apparently, it is true:

• @PreAuthorize is executed after @Valid validation spring-projects/spring-security#6545
• Bean validation is executed before @PreAuthorize spring-projects/spring-boot#10157

It does at least explain why we see a status 400 instead of a 403 (or 401?) for the token tests.

[dennisvang]

The error message

Cannot deserialize value of type
  `java.util.ArrayList<...MetadataSchemaVersionDTO>` 
  from Object value (token `JsonToken.START_OBJECT`)

arises because spring is trying to deserialize an ErrorDTO response, which is a single object instead of the expected array. (JsonToken.START_OBJECT refers to {, whereas a [ is expected for an array)

[dennisvang]

The immediate cause of the failing tests, as indicated by @PatrickDekkerHealthRI (#703), is that the test data created in schemaPublicDTO1() and schemaPublicDTO2() are not valid, according to the MetadataSchemaVersionDTO.

For example, schemaPublicDTO1 has invalid (null) values for type, description, and targetClasses.

However, this should result in a status 400 response with validation results, instead of failing on binding with a JSON parse error. This probably has to do with the TestRestTemplate client that is used in the tests.

[dennisvang]

If we communicate with the API normally, i.e. not via the TestRestTemplate client, it looks like any validation failure at the DTO level results in a status 400 without any validation report, whereas validation failure at a lower level, e.g. entity level, may yield a validation report or a server error (status 500).

For example:

• Minimal POST body for success (status 200 OK):

  [
    {
      "uuid": "string",
      "version": "1.0.0",
      "name": "string",
      "type": "CUSTOM",
      "definition": "",
      "description": "",
      "targetClasses": [],
      "extendsSchemaUuids": []
    }
  ]

• If one or more values are invalid according to MetadataSchemaVersionDTO:

      "definition": null,

  we get a status 400 without any error message:

  {
    "timestamp": 1748267408822,
    "status": 400,
    "error": "Bad Request",
    "path": "/metadata-schemas/import"
  }

  In this case a org.springframework.web.method.annotation.HandlerMethodValidationException is raised.

• If e.g. the definition value is valid according to MetadataSchemaVersionDTO, but fails at a lower level:

      "definition": "invalid",

  we get a status 400 with error message:

  {
    "timestamp": 1748267830164,
    "status": 400,
    "error": "Bad Request",
    "message": "Unable to read SHACL definition"
  }

  In this case a custom nl.dtls.fairdatapoint.entity.exception.ValidationException is raised.

• If we specify e.g. an invalid version string (does not match SemVer type specified in entity):

      "version": "invalid",

  we get a status 500:

  {
    "timestamp": 1748267964228,
    "status": 500,
    "error": "Internal Server Error",
    "path": "/metadata-schemas/import"
  }

Note also that uuid does not appear to be validated at all.

[dennisvang]

From the docs:

Applications must handle both MethodArgumentNotValidException and HandlerMethodValidationException as either may be raised depending on the controller method signature. [...]

and

Method validation may be used in combination with Errors or BindingResult method parameters. However, the controller method is called only if all validation errors are on method parameters with an Errors immediately after. If there are validation errors on any other method parameter then HandlerMethodValidationException is raised.