Support Spring Boot 3.1

[ThorbenLindhauer]

This issue was imported from JIRA:

Field	Value
JIRA Link	CAM-14788
Reporter	@toco-cam
Has restricted visibility comments	true

---

User Story (Required on creation):
As Software Developer I want to use Spring Boot 3.1

Functional Requirements (Required before implementation):
 
Limitations of Scope (Optional):
 
Hints (Optional):

• To be able to support Spring Boot 3 we also have to support Spring 6 (https://spring.io/blog/2022/05/24/preparing-for-spring-boot-3-0)
• The context of this is to update all our Spring Boot starters (incl. External Task Client, ...)

Links:

• is related to https://jira.camunda.com/browse/SUPPORT-13941
• is related to https://jira.camunda.com/browse/SUPPORT-15613
• Update Snakeyaml in Camunda Run to 2.1 #3225
• https://jira.camunda.com/browse/SUPPORT-16552
• is related to https://github.com/camunda/product-hub/issues/1100

Breakdown

Beta Give feedback

1. CI uses JDK 17 as preparation for Spring Boot 3 #3433
   4 of 4
   scope:ci type:subtask version:7.20.0 version:7.20.0-alpha3 +4
   
2. Make spring boot starter modules JDK 17 compatible #3435
   2 of 2
   scope:spring-boot type:subtask version:7.20.0 version:7.20.0-alpha3 +4
   
3. Make run modules JDK 17 compatible #3436
   1 of 1
   scope:run type:subtask version:7.20.0 version:7.20.0-alpha3 +4
   
4. Drop support for handling JPA entities as variables #3447
   5 of 5
   scope:core-api scope:spring-boot type:task version:7.20.0 version:7.20.0-alpha3 +5
   
5. Support Spring 6 for engine-spring #3439
   2 of 2
   type:feature version:7.20.0 version:7.20.0-alpha3 +3
   
6. (Continue) Support for handling JPA entities as variables in spring-boot-starter with Spring Boot 3 #3445
   scope:core-api type:subtask +2
7. In webapp-webjar, use -jakarta module #3440
   scope:spring-boot scope:webapp type:subtask +3
8. Migrate spring-boot-starter modules to Spring Boot 3.1 #3441
   5 of 5
   scope:spring-boot type:subtask version:7.20.0 version:7.20.0-alpha3 +4
   
9. Migrate camunda-run modules to Spring Boot 3.1 #3442
   2 of 2
   scope:run type:subtask version:7.20.0 version:7.20.0-alpha3 +4
   
10. Docker images are built with JDK 17 #3434
    1 of 1
    group:support scope:docker type:task version:7.20.0 version:7.20.0-alpha3 +5
    
11. Support for Spring Boot 3 and Spring 6 is documented #3443
    2 of 2
    scope:documentation scope:spring-boot type:subtask version:7.20.0 version:7.20.0-alpha3 +5
    

Follow up tasks

Beta Give feedback

1. Migrate Spring Boot Starter archetypes to Spring Boot 3.1 #3542
   1 of 1
   type:subtask version:7.20.0 version:7.20.0-alpha3 +3
   
2. Migrate Spring Boot Starter examples to Spring Boot 3.1 #3444
   2 of 2
   type:subtask version:7.20.0 version:7.20.0-alpha3 +3
   

[shahabio]

Hi Guys,
Any update on this?
Thanks.

[toco-cam]

Hello,

We have two great environment topics with J2EE 10 (Wildfly 27) and Springboot 3. Unfortunately, we are not able to work on both topics in parallel. According to our Maintenance Policy Wildfly is an "Adding Environment". Therefore we decided to provide Wildfly 27 support with 7.19 and plan to support Springboot 3 with 7.20.

We do hope for your understanding.

Tobias

[edudant]

I have run Camunda 7.19.0-alpha2 with Spring Boot 3 successfully using this configuration. Although this is not a complete support, it might be useful for others: https://gist.github.com/66cd658ba54439c9052681a0d84d66a9

[toco-cam]

@edudant Thanks a lot for sharing.

[karluto]

I have run Camunda 7.19.0-alpha2 with Spring Boot 3 successfully using this configuration. Although this is not a complete support, it might be useful for others: https://gist.github.com/66cd658ba54439c9052681a0d84d66a9

hava a java code? thx

[shaarmann]

Hi,
Spring Boot 3.0 will reach end-of-life for open-source users in November 2023:
https://spring.io/projects/spring-boot#support
Therefore, it would be great if Camunda 7.20 would already support Spring Boot 3.1., which will be released in May 2023.

[pschalk]

Hi,

I am afraid that Camunda 7.20, if it has the normal release date around October 2023, will be quite late for a support of Spring Boot 3. Since 2.7 will reach EOL already in November 2023, there will not be much time for doing the update of productive Apps. (We are e.g. already working on the Spring Boot 3 Update)

Is there any chance for an earlier support of Boot 3?

[toco-cam]

Hey @pschalk,

Thanks for bringing this up. SpringBoot 3 is a high priority for us in the next release. We will start early with this to be able to release it with an early alpha version. You could begin implementing against an alpha version, which you can replace in October with the official minor release. Would this work for you?

Regards Tobias

[lacribeiro11]

Hi @toco-cam,
I am very interested in this idea. Only to be sure, are talking about Camunda 7.20-alphax?
With best regards,
Luis Ribeiro

[sconrads]

We are building our Spring Boot 3 applications against 7.19.0-alpha4. We have a monorepo with 300+ apps. A few of them are using Camunda. Right now lack of Jakarta support in Camunda is holding back the upgrade for the whole monorepo. When can we expect Jakarta support in eg. camunda-bpm-spring-boot-starter?

[tasso94]

@lacribeiro11 that's correct.
@sconrads 7.20.0 will be released in October.

[lacribeiro11]

Thank you very much @tasso94

[groie]

When can we realistically expect the first 7.20.0-alpha?

[toco-cam]

Hey @groie

SpringBoot 3 is a high priority for us in the next release. We will start early with this to be able to release it with an early alpha version.

After our 7.19 release Mid April we will start looking into this and provide an update in this ticket. Our next alpha is in May but it might not already include this feature.

Thanks for your understanding

Tobias

[teopapath]

Support of jakarta namespace seems critical for many of us. Is there any chance getting a release compatible with spring-boot 3 earlier than October? Also interested in camunda-bpm-spring-boot-starter-rest.

[groie]

We have decided to isolate the embedded Camunda engine from our Spring Applications to a separate Container and Integrate all Delegates over REST rather than as direct JavaDelegates. This will enable us to update all the Business Services and Logic independent of Camunda. This will also enable us to split the Camunda DB-Tables away from our Business-DB.

[toco-cam]

Hello @teopapath

Is there any chance getting a release compatible with spring-boot 3 earlier than October?

It will be delivered with an early alpha release before October.

Also interested in camunda-bpm-spring-boot-starter-rest.

The scope of this epic contains: "... to update all our Spring Boot starters (incl. External Task Client, ...)"

[yanavasileva]

Resources:

• https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Release-Notes
• https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide
• https://github.com/spring-projects/spring-framework/wiki/Upgrading-to-Spring-Framework-6.x
• https://docs.spring.io/spring-framework/docs/5.3.x/javadoc-api/deprecated-list.html
• https://docs.spring.io/spring-boot/docs/2.7.x/api/deprecated-list.html

[yanavasileva]

Summary: Initial evaluation

Spring Boot 3.0 builds on and requires Spring Framework 6. They require Java 17 as a minimum version. Whenever Spring Boot depends on a Jakarta EE specification, Spring Boot 3.0 has upgraded to the version that is included in Jakarta EE 10. For example, Spring Boot 3.0 uses the Servlet 6.0 and JPA 3.1 specifications.

Initial issues

JDK 17

1. Some libraries are not part of the JDK anymore (JAXB, Nashorn) causing not found exceptions in tests and examples. The errors are not observed so far as CI use JDK 8 for IT where the libraries are used.

Stacktrace example

java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlElement
        at org.camunda.bpm.rest.RestIT.testTaskFilterResultContentType(RestIT.java:167)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.annotation.XmlElement
        at org.camunda.bpm.rest.RestIT.testTaskFilterResultContentType(RestIT.java:167)

2. The killing of the Java process seems to be differ from JDK 8 so processes are not terminated properly sometimes in integration tests.

Details and Stacktrace example

The exception is caused by the Java Platform Module System that was introduced in Java 9, particularly its implementation of strong encapsulation (hint). A reflection is used to fetch the process and kill in order to stop the test application

Stacktrace example is for Windows OS, the error occurs for Unix OS as well

java.lang.RuntimeException: Cannot stop managed Spring Boot application!
        at org.camunda.bpm.run.qa.webapps.LoginIT.stopApp(LoginIT.java:89)
...
java.lang.RuntimeException: Cannot fetch windows pid!
	at org.camunda.bpm.run.qa.util.SpringBootManagedContainer.windowsProcessId(SpringBootManagedContainer.java:276)
...
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field private final long java.lang.ProcessImpl.handle accessible: module java.base does not "opens java.lang" to unnamed module @3cb5cdba
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)

Jakarta EE 10

There are imports and dependencies that must be switched to the Jakarta domain in engine, engine-spring, spring-boot-starter, and run modules. Because of that, we need to create some JakartaXXX classes and -jakarta modules as of experience with WildFly 27 work.

Spring 6

1. The migration guides and deprecation javadoc are easy to follow to make adjustments in the code base and the configuration.
2. Spring 6 cannot be used for the current versions of Application servers that we support.
   • Tomcat 9, JBoss 7.4, WildFly 26, WebSphere 9, WebSphere Liberty 22, and WebLogic Server 14 do not support yet Spring 6

Spring Boot 3

1. The migration guides and deprecation javadoc are easy to follow to make adjustments in the code base and the configuration.
2. The latest Spring boot version as of today is Spring Boot 3.0.6 with Spring 6.0.8. Spring Boot 3.1 is scheduled for this month, May 2023. I tested the invoice example with 3.1.0-RC2 and didn't spot issues so far, the available release notes (WIP) don't mention show stoppers as well. Bumping to Spring Boot 3.1 can be considered as nice to be done if the time allows once we moved to 3.0 versions and 3.1 is released.
3. Spring Boot comes with Tomcat 10. We still support Tomcat 9 only. This will affect us during patch updates due to vulnerabilities. The Tomcat versions that we support will be out of sync. For Run distro will bump tomcat version separately if necessary.

Proposal

JDK 17

Impact on our build and test infrastructure.

• CI adjustments:
  • Switch to JDK 17 in Spring Boot and Run stages in CE and EE main pipelines
  • Switch to JDK 17 in Assembly and Distro-EE stages (the compiler source and target are still set in the release parents)
    • pros: applying minimal changes to the Jenkins files to avoid, building different components with different JDK versions
  • ❓ Switch to JDK 17 in docker builds because of the Run image
    • question: what is the impact?
  • Switch to JDK 17 in release jobs, maven-central, and public-nexus freestyle jobs

Technical details: freestyle jobs

Infra involvement will be necessary for the reviews at least if not more

• register jdk 17 to ci/release Jenkins (infra-core: https://github.com/camunda/infra-core/blob/13274dae3fc139abd0ed6dcdb12a64f94e09ef06/camunda-ci/kustomize/base/cambpm/ci/config/jenkins_config_tools.yml)
• add jdk 17 to freestyle jobs definition and adjust tests (jenkins-job-dsl-seed-jobs
  create/build tags and javadoc

• Add JAXB API dependencies IT tests and examples.
  • spring-boot-starter/starter-qa/integration-test-webapp/runtime/pom.xml
  • spring-boot-starter/starter-qa-webapp-ee/pom.xml
  • pros: minimal changes, pom.xml adjustment; the artifacts are not populated with the dependencies.
• adding graaljs dependencies for the script engine usage
  • spring-boot-starter/starter-qa/integration-test-webapp/runtime/pom.xml
  • spring-boot-starter/starter-qa-webapp-ee/pom.xml
  • pros: minimal changes, pom.xml adjustment; the artifacts are not affected by that
• Java process cannot be found and stop during execution of Run integration tests - distro/run/qa/runtime
  • Use Process.pid() to terminate the application process, available since Java 9 https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Process.html#pid()
    • pros: avoid reflection and simplify the code
    • cons: it can differ from one OS (or JDK) to another but that's the case with the current implementation as well
  • Workaround: adding the following options to the VM: --add-opens java.base/java.lang=ALL-UNNAMED (tested on Windows OS only)
    • cons: the options can change in future JDK versions
• After a test failures, some java processes are not terminated. That causes failures during the next test execution. This affects local builds, as on CI further executions are performed on a new agents.
  • no proposal so far

engine

• engine-spring depends on a few engine classes that need to be migrated to Jakarta.
  • Create Jakarta equivalents in engine that can be explicitly used in engine-spring and other modules. This was already done for WildFly 27 for other classes
    • javax.servlet and javax.persistence renamed imports (12 hits in 5 files) - EntityManagerSession, EntityManagerSessionFactory, EntityManagerSessionImpl, JPAEntityMappings, JPAEntityScanner
    • and adjustments are necessary where these classes are used, e.g.: SingleQueryVariableValueCondition (engine), SpringTransactionsProcessEngineConfiguration (engine-spring)
    • pros:
      • half of code can be reused
      • avoid creating a new artifact
    • cons: some of code duplication will be necessary

engine-spring

• Keep support for Spring 4/5.
• Consider Spring 6 support only for Spring Boot Starter, Run distro (and cdi-jakarta. WildFly 27)
• Create a new sub module for Spring 6 which will be used only for places where Spring 6 support is possible. Use transformation for the code. Changes for using the "jakarta" engine classes will be necessary.
  • pros:
    • easier maintenance during spring updates as the modules will be separated
    • easier to differentiate which module to use for Spring 6
    • clean separation between dependencies, including processing of Spring beans, (Technical details: when he artifacts are different, duplication errors will be avoided, they will be loaded from the right classes. Beans are registered based on their names, if two beans exist with the same name processEngine, that will lead to an error eventually.)
    • easier to use the artifact for Application server versions that we want to consider support that support Spring 6 (Tomcat 10/11)
  • cons:
    • once Spring 4/5 are retired, the source code can be adjusted and the cleanup changes will be required
• Jakarta
  • javax.servlet and javax.persistence renamed imports (11 hits in 5 files)
  • dependencies
    • jakarta.persistence-api
    • jakarta.servlet-api, version 6.0
    • hibernate-core-jakarta (for tests)
• Adjust deprecated/removed code
  • AbstractXmlApplicationContext.destroy() -> AbstractXmlApplicationContext.clone()
  • @Required properties removed (for setter) -> @Autowired can be used for initialization of the bean

webjar

(Hint: Contains a single pom.xml file only to package the webapps resources. Spring Boot relies on it work with the webapps.)

• Create webjar-jakarta module. (CE/EE)
  • pros: easier to maintain and reuse in other projects if needed in the future
  • cons: yet another module and artifact

spring-boot-starter

(Hint: The below changes are included for `external task client` as well.)

• Drop support for Spring Boot 2.x as previously done for other major/minor versions.
• Jakarta adjustments
  • javax.annotation, javax.ws, javax.servlet, javax.persistence renamed imports (53 hits in 26 files)
  • add dependencies
    • jakarta.transaction-api (for tests)
    • jakarta.interceptor-api (for tests)
  • Reuse of jakarta modules - rest, webapp, invoice, + webjar
• Deprecated/Removed code
  • AbstractWebSocketMessageBrokerConfigurer -> WebSocketMessageBrokerConfigurer (used in tests)
  • org.springframework.boot.web.server.LocalServerPort -> org.springframework.boot.test.web.server.LocalServerPort (used in tests)
• Using META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports for auto-configurations. (CE/EE)
• Failing tests - current observations
  • RestIT - no hal media type in resource, no proposal so far. The issue cannot be observed in webapps and REST so the root cause should be related to the test setup (CE/EE)
  • RequestScopeIT - resolve logging dependencies
  • SampleCamundaRestApplicationIT - add JAXB dependencies
  • LiquibaseApplicationIT - a known liquibase bug, adjusting the version to 4.18.0 resolves the failure. Spring Boot 3.0 uses Liquibase 4.17.x by default.

run

• Jakarta changes
  • javax.annotation, javax.servlet, javax.inject renamed imports (3 hits in 3 files)
  • Reuse of jakarta modules - invoice, + webjar
• Using META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports for auto-configurations.
• Deprecated/Removed code
  • org.springframework.boot.web.server.LocalServerPort -> org.springframework.boot.test.web.server.LocalServerPort (used in tests)

others

• No specific changes for assert, the tests and the example work
• engine-cdi-jakarta: consider use Spring 6 beans by overwrite the spring version coming from engine module. Looks possible based on local builds, however, didn't test extensively
• WildFly 27: consider using Spring 6 dependencies, however, didn't test extensively
• The changes in examples repos and get-started projects follow the instructions above
• rpa-bridge - if we consider support for it; can be bumped to Spring Boot 3: jaxb API dependency required, spring-cloud version 4.0 and one import adjustment to jakarta. However, I didn't test it.

[yanavasileva]

Open questions:

• engine-spring, only 5 classes, is it worth to have another module/artifact? Use hybrid artifact instead. Risk: issue like WLS failed with the hybrid invoice example.
  • hybrid module will be harder/more complex to achieve so we will not take this path
    • cons
      • only one version can be used during build time (let say Spring 6)
      • this will make hard to load EntityManagerFactoryUtils.getTransactionalEntityManager in SpringEntityManagerSessionFactory class implemented with Spring 5.
      • adjust all of the projects that don't support Spring 6 but depend on Spring to exclude Spring 6 and use Spring 5 instead.
    • pros
      • having one module and only test compatibility module for Spring 5
• engine-spring: easy to solve with code transformation? I.e. no structural changes?
  • as far as I can see no structural changes, only a few classes needs to have adjustments beside the javax -> jakarta changes, e.g.: SpringTransactionsProcessEngineConfiguration#initJpa that extends the super#initJpa
• engine
  • Should/do we need to change the Spring version in the engine module?

Spring 6 pros&cons

document it and users need to update their configuration files

• pros
  • always go with the latest version ( and did it in the past)
  • keep consistant which Spring versions we use across our modules
  • no big effect on the users, we have test coverage.
  • standalone webapps use but we drop support for them
• cons
  • adjust all of the places where Spring 6 cannot be used (e.g.: engine-cdi, tests, maybe more)
  • small refactoring will be required in BpmPlatformXmlLocationTest engine test, which use mock class removed in Spring 6
  • integration tests (application context), exclude spring 6 and use spring 5.
  • spring context xml, exluce spring 6 and overwrite the spring 5. (create test coverage of it)

Spring 5 pros&cons

• cons
  • community support ends (31 Dec 2024 - https://endoflife.date/spring-framework), move the problem to the future to have technical end in the engine.

• ❓ engine: Is not supporting the JPA features an option? We already considered JPA variables legacy when forked Activiti
  • is part of the public API? - yes
    • if we are contractual obligated - create engine-spring jakarta module and exclude jpa (SpringEntityManagerSessionFactory). and then don't create Jakarta classes in engine. then don't have jpa for spring boot... (drop tests, complexity to fiddle around with the engine jakarta classes). Tobi: if the users don't use it, we can remove it.
    • when Spring 5 is not supported any more drop the jpa in engine as well.
    • discuss it with Tobi Conz if we can drop a feature.
  • check forum, JIRA and Support how many people use it. (as input for the discussion)
    • Use cases: https://camunda.slack.com/archives/C055X2FLSLC/p1684237866143159?thread_ts=1684217243.890629&cid=C055X2FLSLC
    • Reasoning, dropping JPA variable support will reduce effort during the implementation of Spring Boot 3 and Spring 6.
    • Impressions: not so many users use the JPA variable feature in spring boot.
    • Next steps, ask Camunda Champions about usage to make a decision how to proceed.

Examples of default Camunda jpa and custom jpa usage

* default Camunda jpa * https://forum.camunda.io/t/activated-jobexecutor-but-still-not-active-working-while-using-mariadb-docker/9185 * https://forum.camunda.io/t/camunda-springboot-not-starting/15322 * https://jira.camunda.com/browse/SUPPORT-6847 novatec-gmbh.de * I was not able to find more examples of the default jpa usage...

• custom jpa
  • https://jira.camunda.com/browse/SUPPORT-15830 helsana.ch
  • https://jira.camunda.com/browse/SUPPORT-12146 rbc.com
  • https://jira.camunda.com/browse/SUPPORT-12811 vkb.de
  • https://jira.camunda.com/browse/SUPPORT-12389 t-systems.com
  • https://jira.camunda.com/browse/SUPPORT-10097
  • https://jira.camunda.com/browse/SUPPORT-10379 bah.com
  • https://jira.camunda.com/browse/SUPPORT-10622 att.com
  • https://jira.camunda.com/browse/SUPPORT-13175 optum.com
  • https://forum.camunda.io/t/externalize-property-file-for-camunda-spring-boot-api/20745
  • https://forum.camunda.io/t/how-to-use-transactional-annotation-in-spring-boot-with-embedded-camunda-engine/31175/2
  • https://forum.camunda.io/t/error-creating-bean-with-name-processenginefactorybean/24301/5
  • https://forum.camunda.io/t/help-needed-for-multiple-datasources-in-spring-boot/20862
  • https://forum.camunda.io/t/configure-spring-boot-multiple-data-source-not-working/20391/4
  • https://forum.camunda.io/t/camunda-spring-boot-transaction-issues/9309
  • https://forum.camunda.io/t/java-delegate-and-jpa-transactions/5206

• engine-cdi: is it necessary? - no
  • Can we exclude the spring dependency coming from engine? - maybe not if it's used in integration test.
• Can we drop Spring 4/5 even we used in AS EE? - example, WLS source code relies on Spring 5
  • We use engine-spring for building the EAR in WLS and WAS:
    https://github.com/camunda/camunda-bpm-platform-ee/blob/master/distro/wls/ear/pom.xml#L77-L81
    • WLS/WAS re-write the code to avoid using the engine-spring? refactor it to drop the Spring 5 it will be nice to have it but it's complex topic/bigger task.
      • there's no out-of-the-box migration to Spring 6.
        • we need the logic from SpringTransactionsProcessEngineConfiguration, we can consider to duplicate it to use it in -ee for WLS and WAS
        • the logic from WebLogicJtaTransactionManager and WebSphereUowTransactionManager is server specific and we cannot avoid it, if there's an equivalent or we re-write it to our source code
        • we can use it with DataSourceTransactionManager and JtaTransactionManager (not Spring version specific)
• For Run distribution user, that we force usage of JDK 17?
  • announce it separately
• Drop support Spring boot 2.x?
  • announce it separately
• Do we need to add anything in the migration guide?
  • Yes, to follow the Spring Boot 3 and Spring 6 migration guides. Also Java support.
  • Depending on our implementation of engine-spring we need to consider note about it too.
• What about testing?
  • We need to cover Spring 6 support (engine integration tests) for servers that we claim support for it (e.g. WildFly 27).
  • Manual testing:
    • Test Spring Boot Starter extensively: rest, webapps, external task client, different dbs and browsers
    • Test Run distro extensively: with/without rest, webapps, invoice example, (swaggerui), different dbs and browsers
• (Impact of switch to JDK 17 in docker builds because of the Run image) For users that need different JDK version in Docker, document to create docker image on their side and overwrite the jdk as they please.

Decisions:

• rpa-bridge - create ticket to support Spring Boot 3 and pass it to Tobi Conz
• Announce drop of support for:
  • Spring 4
  • Spring Boot 2.x
  • JDK < 17 for Run distribution
• webjar: no need for -jakarta module, as the webjar is used in spring-boot-starter only so we just need to migrate it to jakarta.

[yanavasileva]

Hello @iamvajid,

We started working on ticket.
We currently expect to release the feature with the one of the next alpha releases in the upcoming months. Note that this can be subject to change.
We will add comment to the ticket when the feature is implemented.

Best regards,
Yana

[yanavasileva]

Sync June 9th 2023

Results

• ✅ CI and code run on JDK 17 - merged
• 🟨 Drop support for handling JPA entities as variables #3447 - in a review
• 🟨 Support Spring 6 for engine-spring #3439 - in implementation
  • remaining: add an engine IT test using SpringProcessApplication for WildFly 27 to test Spring 6 support for this application server

Next

• Spring Boot 3 support for Spring Boot Starter
  • In webapp-webjar, use -jakarta module #3440
  • Migrate spring-boot-starter modules to Spring Boot 3.1 #3441

Decisions

• Petros will join the effort. Yana gives introduction to him. Collaboration will be decided by them.

Questions

• For when do we schedule next sync meeting?
  • June 26th
• What do we want to test with SpringProcessApplication for WildFly
  • WildFly doesn't support SpringProcessApplication scenario => engine IT is not required for Spring 6. (docs)

[yanavasileva]

Sync June 26th 2023

Results

• ✅ Drop support for handling JPA entities as variables #3447 - done
• ✅ Docker images are built with JDK 17 #3434 - done
• ✅ Support Spring 6 for engine-spring #3439 - done
• 🟨 Migrate spring-boot-starter modules to Spring Boot 3.1 #3441 - CI green on PR, to be reviewed
• 🟨 Support for Spring Boot 3 and Spring 6 is documented #3443 - to be reviewed
• 🟨 Migrate camunda-run modules to Spring Boot 3.1 #3442 - WIP
• 🟨 Migrate Spring Boot Starter examples to Spring Boot 3.1 #3444 - examples done, archetypes and get-started pending

Next

• wrap up starter and run and test them
• archetypes

Remaining

• follow ups

Questions

• RestIT: do we continue with the alternative and create follow up ticket to replace the jersey apache client?
• remark: java-dependency-tree action must be updated as well, to use JDK-17.

[peterAdc]

will springBoot 2.x still be supported on camunda 7.20 ?

[yanavasileva]

will springBoot 2.x still be supported on camunda 7.20 ?

No, Spring Boot Starter will support only Spring Boot 3 onwards.
Docs: https://docs.camunda.org/enterprise/announcement/#camunda-platform-7-20

[yanavasileva]

Sync July 6th 2023

Results

• ✅ Support for Spring Boot 3 and Spring 6 is documented #3443 - done
• 🟨 Migrate spring-boot-starter modules to Spring Boot 3.1 #3441 - to be tested
• 🟨 Migrate camunda-run modules to Spring Boot 3.1 #3442 - to be tested
• ✅ Migrate Spring Boot Starter examples to Spring Boot 3.1 #3444 - done
• ✅ Migrate Spring Boot Starter archetypes to Spring Boot 3.1  #3542 - done

Remaining

• follow ups
  • Run distribution performs JDK version check on start up #3543

Questions

• ...

[yanavasileva]

Follow up tasks

• Support Spring 6 in engine core #3437
• Improve the JPA variables migration test to fetch persisted values in 7.19 #3560
• RestIT test works with (jakarta.ws.rs.core.MediaType) Hal#APPLICATION_HAL_JSON_TYPE #3561
• Run distribution performs JDK version check on start up #3543

[yanavasileva]

To all interested, the ticket has been completed.
Support of Spring Boot 3.1 will be available with Camunda Platform 7.20.0-alpha3 that will be released tomorrow.
Please try it out, your feedback is important to us. You can contact us in the forum.

The upcoming Camunda Platform 7.20.0 minor release is scheduled for 10th of October 2023.

[ThorbenLindhauer]

Thank you @yanavasileva!

[EasyGo-Digital]

Now it supports SB 3, but still not compatible with usage of spring cloud
I have this issue msg
consider defining a bean of type 'com.netflix.discovery.abstractdiscoveryclientoptionalargs' in your configuration.

It seems like camunda SB starters are overiding some dependencies in SB 3

[ThorbenLindhauer]

Can you please share a minimal example project that reproduces the problem? Otherwise it will hard for us to analyze.

[yangle94]

There was an issue with the integration of spring boot 3.1, camunda bpm spring boot starter 7.20-alpha3, and keycloak admin client 22.0.1. Please use it in the project directory: ./gradlew bootjar, will report an error.

https://github.com/yangle94/camunda-keycloak-test/blob/main/build.gradle

[yanavasileva]

Hi @yangle94,

Thank you for reaching out to us with this. However, I see that the keycloak extension has not been adjusted to adopt Spring Boot 3, therefore it's only compatible with Camunda Platform 7.19.
Please reach out to the keyclock extension maintainers of https://github.com/camunda-community-hub/camunda-platform-7-keycloak. I believe they can help you better with information, if the extension can be used with Spring Boot Starter 7.20.0-alpha3 and/or when can it be used with that version.

Best regards,
Yana

[yangle94]

@yanavasileva Hello, I am using a version that supports camunda 7.20. Please refer to this PR camunda-community-hub/camunda-platform-7-keycloak#122 .

[yanavasileva]

@yangle94, after adding a datasource in the application.properties file and the respective dependencies (org.springframework.boot:spring-boot-starter-jdbc and database driver) the spring boot application starts successfully for me (see below).

Could you please open a new topic in the forum and describe what issue do you observe. It seems to be a better suited channel to continue the discussion.

Application log output

~/camunda-keycloak-test (main)
$ ./gradlew clean bootRun

> Task :bootRun

 ____                                 _         ____  _       _    __
/ ___| __ _ _ __ ___  _   _ _ __   __| | __ _  |  _ \| | __ _| |_ / _| ___  _ __ _ __ ___
| |   / _` | '_ ` _ \| | | | '_ \ / _` |/ _` | | |_) | |/ _` | __| |_ / _ \| '__| '_ ` _ \
| |__| (_| | | | | | | |_| | | | | (_| | (_| | |  __/| | (_| | |_|  _| (_) | |  | | | | | |
\____/\__,_|_| |_| |_|\__,_|_| |_|\__,_|\__,_| |_|   |_|\__,_|\__|_|  \___/|_|  |_| |_| |_|

  Spring-Boot:  (v3.1.2)
  Camunda Platform: (v7.20.0-alpha3)
  Camunda Platform Spring Boot Starter: (v7.20.0-alpha3)

2023-09-13T10:15:01.909+02:00  INFO 26176 --- [           main] c.e.test.CamundaKeycloakTestApplication  : Starting CamundaKeycloakTestApplication using Java 17.0.4.1 with PID 26176 (C:\workspace\camunda-keycloak-test\build\classes\java\main started by Yana in C:\workspace\camunda-keycloak-test)
2023-09-13T10:15:01.914+02:00  INFO 26176 --- [           main] c.e.test.CamundaKeycloakTestApplication  : No active profile set, falling back to 1 default profile: "default"
2023-09-13T10:15:02.853+02:00  INFO 26176 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http)
2023-09-13T10:15:02.861+02:00  INFO 26176 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2023-09-13T10:15:02.861+02:00  INFO 26176 --- [           main] o.apache.catalina.core.StandardEngine    : Starting Servlet engine: [Apache Tomcat/10.1.11]
2023-09-13T10:15:02.955+02:00  INFO 26176 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
2023-09-13T10:15:02.956+02:00  INFO 26176 --- [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 991 ms
2023-09-13T10:15:03.330+02:00  INFO 26176 --- [           main] org.camunda.bpm.spring.boot              : STARTER-SB040 Setting up jobExecutor with corePoolSize=3, maxPoolSize:10
2023-09-13T10:15:03.378+02:00  INFO 26176 --- [           main] org.camunda.bpm.engine.cfg               : ENGINE-12003 Plugin 'CompositeProcessEnginePlugin[genericPropertiesConfiguration, camundaProcessEngineConfiguration, camundaDatasourceConfiguration, camundaJobConfiguration, camundaHistoryConfiguration, camundaMetricsConfiguration, camundaAuthorizationConfiguration, camundaDeploymentConfiguration, failedJobConfiguration, eventPublisherPlugin, ApplicationContextClassloaderSwitchPlugin]' activated on process engine 'default'
2023-09-13T10:15:04.416+02:00  INFO 26176 --- [           main] org.camunda.bpm.spring.boot              : STARTER-SB021 Auto-Deploying resources: []
2023-09-13T10:15:04.419+02:00  INFO 26176 --- [           main] o.c.b.s.b.s.event.EventPublisherPlugin   : EVENTING-001: Initialized Camunda Spring Boot Eventing Engine Plugin.
2023-09-13T10:15:04.420+02:00  INFO 26176 --- [           main] o.c.b.s.b.s.event.EventPublisherPlugin   : EVENTING-003: Task events will be published as Spring Events.
2023-09-13T10:15:04.420+02:00  INFO 26176 --- [           main] o.c.b.s.b.s.event.EventPublisherPlugin   : EVENTING-005: Execution events will be published as Spring Events.
2023-09-13T10:15:04.420+02:00  INFO 26176 --- [           main] o.c.b.s.b.s.event.EventPublisherPlugin   : EVENTING-009: Listeners will not be invoked if a skipCustomListeners API parameter is set to true by user.
2023-09-13T10:15:04.425+02:00  INFO 26176 --- [           main] o.c.b.s.b.s.event.EventPublisherPlugin   : EVENTING-007: History events will be published as Spring events.
2023-09-13T10:15:04.597+02:00  INFO 26176 --- [           main] org.camunda.feel.FeelEngine              : Engine created. [value-mapper: CompositeValueMapper(List(org.camunda.feel.impl.JavaValueMapper@5866731)), function-provider: org.camunda.bpm.dmn.feel.impl.scala.fun2023-09-13T10:15:04.674+02:00  INFO 26176 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Starting...
2023-09-13T10:15:04.841+02:00  INFO 26176 --- [           main] com.zaxxer.hikari.pool.HikariPool        : HikariPool-1 - Added connection conn0: url=jdbc:h2:mem:e9b3d23b-8992-4571-bd75-04fce16b8ac7 user=SA
2023-09-13T10:15:04.842+02:00  INFO 26176 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Start completed.
Standard Commons Logging discovery in action with spring-jcl: please remove commons-logging.jar from classpath in order to avoid potential conflicts
2023-09-13T10:15:06.423+02:00  INFO 26176 --- [           main] org.camunda.bpm.connect                  : CNCT-01004 Discovered provider for connector id 'http-connector' and class 'org.camunda.connect.httpclient.impl.HttpConnectorImpl': 'org.camunda.connect.httpclient.impl.HttpConnectorProviderImpl'
2023-09-13T10:15:06.425+02:00  INFO 26176 --- [           main] org.camunda.bpm.connect                  : CNCT-01004 Discovered provider for connector id 'soap-http-connector' and class 'org.camunda.connect.httpclient.soap.impl.SoapHttpConnectorImpl': 'org.camunda.connect.httpclient.soap.impl.SoapHttpConnectorProviderImpl'
2023-09-13T10:15:06.549+02:00  INFO 26176 --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03016 Performing database operation 'create' on component 'engine' with resource 'org/camunda/bpm/engine/db/create/activiti.h2.create.engine.sql'
2023-09-13T10:15:06.574+02:00  INFO 26176 --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03016 Performing database operation 'create' on component 'history' with resource 'org/camunda/bpm/engine/db/create/activiti.h2.create.history.sql'
2023-09-13T10:15:06.582+02:00  INFO 26176 --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03016 Performing database operation 'create' on component 'identity' with resource 'org/camunda/bpm/engine/db/create/activiti.h2.create.identity.sql'
2023-09-13T10:15:06.592+02:00  INFO 26176 --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03016 Performing database operation 'create' on component 'case.engine' with resource 'org/camunda/bpm/engine/db/create/activiti.h2.create.case.engine.sql'
2023-09-13T10:15:06.595+02:00  INFO 26176 --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03016 Performing database operation 'create' on component 'case.history' with resource 'org/camunda/bpm/engine/db/create/activiti.h2.create.case.history.sql'
2023-09-13T10:15:06.597+02:00  INFO 26176 --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03016 Performing database operation 'create' on component 'decision.engine' with resource 'org/camunda/bpm/engine/db/create/activiti.h2.create.decision.engine.sql'
2023-09-13T10:15:06.601+02:00  INFO 26176 --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03016 Performing database operation 'create' on component 'decision.history' with resource 'org/camunda/bpm/engine/db/create/activiti.h2.create.decision.history.sql'
2023-09-13T10:15:06.633+02:00  INFO 26176 --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03067 No history level property found in database
2023-09-13T10:15:06.633+02:00  INFO 26176 --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03065 Creating historyLevel property in database for level: HistoryLevelFull(name=full, id=3)
2023-09-13T10:15:06.655+02:00  INFO 26176 --- [           main] org.camunda.bpm.engine                   : ENGINE-00001 Process Engine default created.
2023-09-13T10:15:06.739+02:00  INFO 26176 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
2023-09-13T10:15:06.747+02:00  INFO 26176 --- [           main] c.e.test.CamundaKeycloakTestApplication  : Started CamundaKeycloakTestApplication in 5.154 seconds (process running for 5.493)
2023-09-13T10:15:06.749+02:00  INFO 26176 --- [           main] org.camunda.bpm.engine.jobexecutor       : ENGINE-14014 Starting up the JobExecutor[org.camunda.bpm.engine.spring.components.jobexecutor.SpringJobExecutor].
2023-09-13T10:15:06.750+02:00  INFO 26176 --- [ingJobExecutor]] org.camunda.bpm.engine.jobexecutor       : ENGINE-14018 JobExecutor[org.camunda.bpm.engine.spring.components.jobexecutor.SpringJobExecutor] starting to acquire jobs

[yangle94]

@yanavasileva please this issure

[yangle94]

@yanavasileva please this issure

#3781