PoC for Spring 7 / Spring Boot 4

Development
1

Hi folks,

in the last two weeks I was working on support for Spring 7 and Spring Boot 4. A lot of moving parts are still not discussed in the community so please understand the branch I am going to explain here as a proof of concept, not a finished proposal. I wanted to make sure that Operaton will in genreral work with Spring 7 and Spring Boot 4, and that we won’t run into any compatibility issue with the engine or engine-rest itself.

If you install the current state of this branch into your local repository, you can require the following dependencies in a Spring Boot 4 application and try it out. The starter is build for Spring Boot 4 RC2:

        <dependency>
            <groupId>org.operaton.bpm.springboot4</groupId>
            <artifactId>operaton-bpm-spring-boot-starter-rest</artifactId>
            <version>1.1.0-SNAPSHOT</version>
        </dependency>

        <dependency>
            <groupId>org.operaton.bpm.springboot4</groupId>
            <artifactId>operaton-bpm-spring-boot-starter-webapp</artifactId>
            <version>1.1.0-SNAPSHOT</version>
        </dependency>

        <dependency>
            <groupId>org.operaton.bpm.springboot4</groupId>
            <artifactId>operaton-bpm-spring-boot-starter-security</artifactId>
            <version>1.1.0-SNAPSHOT</version>
        </dependency>

These are not yet published to any Maven Repo, you need to build locally from source!

In my first test setups everything worked, the unit tests also seem to work for me.

In this PoC I copied the Spring Boot starter into a new spring-boot-4-starte, adapted the dependencies, fixed some imports and some security behavior. Neither this approach is a given, nor the dependency management I introduced for maintaining two different spring and spring boot versions.

There is some potential for a cleaner / better Spring Security setup which is an ongoing work in progress. This PoC is working, but it’s not yet pretty, in my opinion.

Things you can do which would be really helpful to the project right now:

  • Check out this branch, install it into your local maven repo and test it in a Spring Boot 4 application.
  • Share your thoughts about the structure and on how we can manage different Spring versions in our Maven setup
  • Share your thoughts on our “run” distribution: Should we switch it over to Spring Boot 4?
  • Share your thoughts on our “tomcat” distribution: Should we switch it over to Spring 7?
  • When should we drop Spring Boot 3 support? Should there be an overlap with the time we support Spring Boot 4? 4 will be released in November, 3 will be EOL mid 2026
  • Share any concerns, ideas, frustrations you have with the Spring Boot 4 support and its impact on our software
2 Likes
2

Personally, I think copying the Spring Boot 3 starter and having a short timespan where we support both is a sensible idea. Boot 4 will be released in November, Boot 3.5 will bei EOL in June, so there are only 6 months time for users to switch over. Just changing the Spring Boot 3 starter in place would mean that all of our users on Spring Boot 3 needed to upgrade to Spring Boot 4 in order to use Operaton 1.1.0. This is a lot to ask, and might put them in limbo of they use other libraries which are not yet Spring Boot 4 ready. With some months as a grace period we could then deprecate or remove the Spring Boot 3 starter once it is EOL.

1 Like
3

This is a great initiative. Thank you for taking the steps to explore it until a working state. I started “Operaton 2.0” discussion with SpringBoot 4 in mind next to other major challenges. And first I thought, we can not or should not have Spring Boot 3 and 4 support at the same time in the same development stream.

Today, I am thinking different because you have shown that this can co-exist. This is a great value if we can leave Operaton users still work with SB3, while new projects can have SB4 already.

For the distributions I think they should advance to Spring 7/SpringBoot 4 soon. Users that embed Operaton with SB3/S7 won’t have to change anything. But those that use the distributions should get the latest state of the art.

We should also start to work on migration recipes that upgrade an Operaton SB3 app to SB4. The existing repository is dedicated to the Camunda-to-Operaton migration, so sounds like the need for a new repository for Operaton-self refactorings.

I will soon explore your PoC in detail.

2 Likes
4

Hi Karsten, thanks for your response!

This will be tricky or even impossible to do, because in most Spring Boot applications we are not “alone”. The migration from Boot 3 to 4 is breaking, so all other integrations that people have in their applications will need to update to newer versions of the spring boot starters, and we don’t know them. For example if somebody migrates a Spring Boot 3 app which uses Jersey to 4, they need to include the Spring Boot Jackson 2 compatibility module, too. There are many such constellations which are described here: Spring Boot 4.0 Migration Guide · spring-projects/spring-boot Wiki · GitHub

In my opinion we cannot offer this reliably and a Operaton-focused migration recipe from 3 to 4 will cause a lot of trouble in our users projects for which I wouldn’t want to be blamed

5

You are right on this, forget it.

6

Update: @cachescrubber has implemented a second PoC on branch GitHub - operaton/operaton at explore/spring-7-upgrade

Further he summarized major dependency changes we need to tackle in this issue: