First of all, thanks for all the work on Operaton and the recent Spring Boot 4 support efforts.
I have a question regarding the engine-rest module. As far as I understand, the REST API is currently still based on JAX-RS, with support for runtimes such as Jersey, RESTEasy, and historically Apache Wink, similar to the original Camunda 7 implementation.
Are there any plans or ongoing discussions around supporting the engine-rest endpoints through Spring MVC (@RestController)?
The reason I’m asking is that the Spring ecosystem increasingly favors Spring MVC and other Spring-native web technologies, and some organizations no longer support Jersey-based endpoints in their internal development frameworks. For Spring Boot users, introducing a second web stack can therefore become an adoption hurdle. (To be clear, I’m specifically referring to the built-in engine-rest API, not custom application endpoints.)
If Spring MVC support is not currently on the roadmap, would the community be interested in a contribution that adds a Spring MVC based implementation alongside the existing JAX-RS implementations, while preserving REST API compatibility?
This is something we discussed during the Spring Boot 4 migration, because for a long time it was unclear if the new Jersey version could be included in Spring Boot 4 at all.
The issue is not the effort for a one time contribution but the ongoing maintenance. Currently our REST definitions are a single point of maintenance for every runtime, be it Jakarta EE, Spring Boot, Quarkus and so there is one single point of maintenance. If we duplicated those definitions for Spring MVC, we would need to do every change twice and risk both implementations diverging or behaving differently.
These issues could be worked around by
Running an agnostic test suite against both implementations
generating the interfaces from OpenAPI (though routing and marshalling would be maintained manually)
You wrote that some organizations don’t allow jersey-based endpoints anymore, so this is a constraint you and others are already experiencing? I can see how wiring JAX-RS based / jersey based endpoints into Spring Security could be a hurdle, if it requires finer configuration than our Spring Boot starter already allows.
I’d be interested about more opinions and experience from contributors and users. I think a good developer experience is important, and if we support frameworks we should make sure that the integration is well done and idiomatic to the framework. Still, I see a lot of possible maintenance effort here and we should weigh the benefits and have an agreement in the developer team before you (or somebody else) puts in the work. There is a lot to do and we need to prioritize or developer hours.
I’ll make others aware of this post, hopefully we’ll get a good discussion going.
When going in such a direction I would intensively consider to derive the implementation(s) from the OpenAPI spec, which is the single source of truth.
Ideally, I would avoid to have 2 implementations, or at least factor out common logic into a shared REST module. It must be assured that whatever change is done, users of the API are not affected in any (corner) case.
I do not consider the engine-rest implementation as public API. However, it has a huge impact. At least a decision here requires an ADR, and a possible change should either been opt-in when made available in a feature release, or considered for a major release. I would feel better with a smooth transition with having both for a short term with the clear goal to remove the Jersey based one with the following major release.
@kthoms I agree that this needs to be carefully planned out. Just to clarify, your goal would be to remove the Jersey based Spring Boot starter, not to remove / replace the whole enigine-rest module?
@javahippie to answer your question, yes we are already experiencing this limitation. I foresee for the short term we will need to write our self-maintained adapter, and build that on top of Operaton