Chore: upgrade to spring boot 4

[netomi]

This fixes #1843, #1608 .

Changes that are worth to mention:

• use builtin @retryable support instead of explicit spring-retry
• adjust for modularization of spring boot 4
• adjust for changes in hibernate 7 wrt auto-commit in test cases
• use the hibernate version from the spring bom to keep them in sync
• update testcontainers to 2.0.3 and adjust tests accordingly
• replace explicit jackson use from jackson 2 to jackson 3 used by spring boot
• DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES is now disabled by default in jackson 3, no need for a custom ObjectMapper in some cases anymore
• use JsonMapper.shared() or the injected bean instead of creating a new ObjectMapper instance
• update elasticsearch to 9.2.8 to align with the client version that is used by spring boot
• replace all jakarta annotations wrt Nullability to jspecify ones
• some cases were using @NotNull from the jakarta bean validation package which were wrong anyways to the jspecify ones
• keep the bean validation constraints in Property and Entity classes where these annotations are evaluated at runtime

jackson 2 is still inherited from various transitive dependencies, but the application code should not use it but prefer jackson 3 to avoid unexpected side-effects. The annotations are still coming from the 2.21 package as explained in the release notes: https://github.com/FasterXML/jackson/wiki/Jackson-Release-3.0

https://spring.io/blog/2025/10/07/introducing-jackson-3-support-in-spring

That will stay like that for a while.

[netomi]

that is now the default in jackson 3

[gnugomez]

question: I don't see any mention in the issue description about the JavaTimeModule, since tests are passing I could assume that this is now included by default as well, but could you confirm that?

I've tried to do some research but it's a bit hard since this library hasn't changed it's api for the longest and I find a lot of mentions to the old usage

[netomi]

https://spring.io/blog/2025/10/07/introducing-jackson-3-support-in-spring#jackson-modules

though I am not 100% sure about the way dates are now serialized, we need to test that.

[gnugomez]

yeah, we should be testing that, I found another occurrence in AuthTokenConverter

[netomi]

added a unit test for that. With Jackson3 you the format changed indeed, but it is able to read both, the old and new format. Serializing will use the ISO timestamps now.

So we can adopt the new default while being backwards compatible with what is currently stored in the DB

[autumnfound]

question: On hibernate, do we actually use it, and do we rely on the annotations for value processing/validation? JSpecify specifically does not work with Hibernate for value processing, where it does do something w/ the Jakarta annotations. If we make use of that feature, we may be introducing hard to spot issues under the hood w/ db entity validation if we aren't careful.

[netomi]

The remaining jakarta validation contraints that have not been migrated to jspecify nullability annotations as they serve a different purpose. They are for bean validation as explained here: https://docs.spring.io/spring-framework/reference/core/validation/beanvalidation.html

So ideally spring will automatically validate these instances at runtime if they are used in a way that spring can intercept. For example on configuration properties or on DTOs.

General nullability annotations are not checked or enforced at runtime, they are merely a hint for the IDE but they are really helpful imho.

[autumnfound]

So ideally spring will automatically validate these instances at runtime if they are used in a way that spring can intercept. For example on configuration properties or on DTOs.

For sure! I'm more pointing out for the 3 entity classes that have been swapped over to use the JSpecify Nullable instead of the Jakarta spec Nullable, and want to make sure we weren't using that as part of bean validation.

[netomi]

The nullability annotation on the entity classes (Extension and UserData afaics) is not on columns / properties but on method parameters.

[netomi]

@svor could you also please take a look at this PR and test it in your environment. Bumping the spring boot framework to 4 (as 3.5 reaches end-of-support this week) requires to bump elasticsearch to 9+. We pick the same server version as the client that comes bundles with spring boot.