Investigate Spring Boot 3.0.0 support

[berndruecker]

Spring Boot 3 is out - we need to investigate if this is compatible, or if we need to do some work to make it so.

Probably a good candidate to do together with #275

See also #270

[berndruecker]

Let's also add a compatibility table to the docs (like with C7), see https://forum.camunda.io/t/zeebe-and-spring-boot-compatibility/41824/4 - added https://github.com/camunda-community-hub/spring-zeebe/blob/master/README.md#version-compatibility as a basis

[berndruecker]

See also #308 (comment):

Also, we should consider that Spring Boot 3 requires JDK 17, so we could plan to upgrade to the 17th version straightforwardly.
If Spring Zeebe could have its release versions (not bound to Zeebe's versions) we could say that version 8, for example, could support only JDK 8, and there could be a separate release branch (in case of security updates or backports). And version 9, for example, break backward compatibility and will have a Spring Boot 3.0 (major version upgrade - I am almost sure that it will not work with Spring Boot 2.x) and JDK 17, plus connectors in the main starter. But it has its own drawbacks (like compatibility matrix, support of two versions for some period of time, etc.) so I can't say for sure if it is an option. But for Semver conventions, it would be definitely a plus (I as a user update from one minor version to another, and backward compatibility isn't broken, but if I want a fresh major version I should fix backward compatibility conflicts).

[korthout]

Many teams at Camunda need to support multiple versions of their products. At Zeebe, we've automated backporting changes using backport-action.

It removes most of the need to cherry-pick commits to the supported versions manually but can also be used to forward-port if you make changes on your supported versions first. Note that you should aim to keep your implementations close because the action cannot automatically resolve conflicts for you.

@berndruecker If you're interested, I could also set it up for the Spring-Zeebe repo.

[berndruecker]

I only found the following two direct problem in my first stab:

1. We need remove the deprecated SocketUtil usage and switch to the new TestSocketUtil ( Introduce TestSocketUtils as a replacement for SocketUtils spring-projects/spring-framework#29132)
2. Exception on context startup (bean of type 'io.camunda.zeebe.client.ZeebeClientBuilder' that could not be found) - see stacktrace below - can be observed e.g. in the test cases for the Connector Runtime. This is because the spring.factories approach have been removed in SB3 (see e.g. https://github.com/spring-projects/spring-boot/issues/32566), so we need to adapt to the new approach

Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'zeebeClientObjectFactory' defined in io.camunda.zeebe.spring.client.ZeebeClientSpringConfiguration: Unsatisfied dependency expres
sed through method 'zeebeClientObjectFactory' parameter 0: No qualifying bean of type 'io.camunda.zeebe.client.ZeebeClientBuilder' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}

[berndruecker]

Good news: The two changes required will also work with Spring Boot >= 2.7.6, so I prepared a PR to push them into main immediately: #315 - I will do some further testing but we might already be Spring Boot 3 compatible then :-)

[berndruecker]

Seems like there are also differences in logging - looks like a bug in Spring Boot: spring-projects/spring-boot#33854 - might require adding a slf4j-api dependency in your own projects

[berndruecker]

Fixed with 8.1.5 released today, this supports SB 3 (and is backwards compatible with SB 2.7.7)