WildFly 15 support for Camunda


#1

Hi,

Is there Camund BPM download available for WildFly 15? We are using Camunda modules in WildFly server & going to upgrade to WF 15/16.

As of now WF 11 seems to be available for download: https://camunda.org/release/camunda-bpm/wildfly11/7.10/

Thanks!


#2

Hi @valsaraj_pv,

welcome to the forum!

In https://docs.camunda.org/manual/7.10/introduction/supported-environments/ you can see that for Camunda BPM 7.10 we support WildFly up to version 14.
You can find that download here: https://camunda.org/release/camunda-bpm/wildfly/7.10/.

With Camunda BPM 7.11 we will add support for WildFly 15 as well, you can try the released alpha versions of 7.11 from here: https://camunda.org/release/camunda-bpm/wildfly/7.11/

Hope that helps.

Cheers,
Tobias


#3

Camunda BPM 7.11 will work with WildFly-16 also?
Currently we are using Camunda 7.8 embedded in WildFly 8.2. Is it possible to upgrade to Camunda BPM 7.11 or later on WildFly-8.2?


#4

Hi @valsaraj_pv,

WildFly 16 will be supported as well with Camunda BPM 7.11.

You can upgrade to Camunda BPM 7.11 on a WildFly 8.2.
However, there will be no pre-packaged distribution anymore (7.9 was the last version to offer this).
Please have a look at the installation guide for this scenario.

Hope that helps.

Best,
Tobias


#5

Currently we are using shared process engine. If we change to application managed process engine, will this wildfly - camunda module dependency can be eliminated?

Other option is to use standalone Camunda server. In that case can we use existing Java API code in application to connect to standalone Camunda process engine?


#6

Hi @valsaraj_pv,

the shared process engine setup is the recommended way of using Camunda BPM if you have no requirements that speak against that setup.

With that said, you can of course go for the embedded engine setup (application managed). The module dependency would be eliminated by that, yes. But since there is a provided module that should fit your case, I would still recommend going this way. Why is that? Because besides other things, bootstrapping and managing the lifecycle of the engine is up to you then. If you go for Spring Boot here, you get a head-start for this of course. But eliminating the module dependency by introducing a lot of other new challenges seems like a bad trade-off.

As for the remote engine setup, this is recommended for applications that have specific security concerns or do not use Java but want to make use of the process engine. Since the engine is a remote service then, we recommend using the REST API to communicate with it. So you will probably be forced to rewrite a lot of your communication with the engine.

Hope that helps.

Best,
Tobias


#7

OK. When we can expect Camunda BPM 7.11 support for WildFly 16?


#8

Hi,

the release of Camunda BPM 7.11 is scheduled for May 31st.

Best,
Tobias


#9

Hi,

We wish to jointly deploy Camunda (with our product) in a WildFly 17, but the current release notes (Camunda 7.11) say only up to WildFly 16 is supported (and in a first trial the JBoss plugin crashes). Any ideas if/when we can expect Camunda to support WildFly 17?

(If you need more details, e.g. a crashlog, please feel free to reach out to me.)

update: I tried with the original module as well as with the camunda-wildfly8-subsystem, neither works. The likely cause is that WildFly reports Core 9.0.2.Final). Any perspective when this could be supported?


#10

Hi @Mel_Gru,

WildFly 17 is on the roadmap for Camunda BPM 7.12 (due November 30, 2019).
Make sure to keep an eye on the Camunda Blog to stay up-to-date with the latest versions. :+1:

Thanks for the offer, we’ll happily reach out if we hit any road blocks.

Best,
Tobias