New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Patch for the wildlfy subsystem for WF 14 (possibly 12 and 13) #306
Conversation
Hi Joe, Thanks for the contribution. Best regards, |
Hi @kifj, I already reviewed your pull request last week. It's awesome, thanks for the contribution! However, it breaks support for WildFly 8 and we still need to provide support for that. Because of this, we decided to move the subsystem with your changes to WildFly 10 and keep the old subsystem in WildFly 8. This will result in new Maven coordinates for WildFly 8 users. I'm still working on making the needed changes for this, so I'll keep the ticket open until everything is finished. Cheers, |
Thank you, I expected something like this, and that this pull request may need more rework to be able to have 2 different subsystems for the different wildfy versions. |
Hi @kifj, I'm closing this PR since I made the necessary changes needed for everything to function properly. The project structure will still change, since from now on, we'll cover only the latest version of WildFly in our tests. Thanks again for the contribution. It really sped things up. Cheers, |
Thank you |
has this change already been merged in some version? We have a WF14 project using JavaEE 8, so no way to go back to version < WF13. Exist some pacaging install for wildlfy?(cli scripts + modules strcutres and pkgs) |
check release 7.10 which is announced to be released for Friday; last alpha includes already a WF 14 distro build |
Hi kifj, where can I get this WF 14 release of Camunda? At https://camunda.org/release/camunda-bpm/ I only see these: |
Hi @phija, From 7.10 onwards we will release Camunda BPM only with the latest WildFly version. That's why we stopped appending WildFly version numbers to the name. You can see Cheers, |
Thank you guys! |
Exists a bundle with the required modules an a cli script that can be applied to new versions? |
Hi @alacambra, The newest version of WildFly when Camunda BPM 7.10 came out on 30.11.2018 was WildFly 14, so Camunda BPM 7.10 is compatible with WildFly versions up to 14. You can transfer the required modules from the available WildFly distro. They will work with WildFly versions 10-14 (WildFly 9 is not supported). If you want to use WildFly 8, you will need to download the modules as a separate archive. You can find the instructions on how to do a manual install (and the link to the WildFly 8 modules) here. WildFly 15 was just recently released, and we will add support for it, and any new version that comes out (and we have enough time to make sure that everything works) before the 7.11 release of Camunda BPM. Best, |
Thanks @koevskinikola. Is somewhere written which are the exact needed modules? The reason why I am looking for that is because it looks like that the jaeger tracing modules has something buggy that ends up with slow redeployments (about 30s). I found that WF14 was buggy but has been fixed in some nightbuild but of course I need to reinstall the modules. "12:51:38,976 WARN [io.jaegertracing.internal.senders.SenderResolver] (ServerService Thread Pool -- 132) No suitable sender found. Using NoopSender, meaning that data will not be sent anywhere! Thanks for your help! |
@alacambra, the installation guide specifies where they are. You can also see them in the In any case, it would be better if you post a help request in the forum, you'll get more input than in a closed PR. Cheers, |
prevent historyLevel mismatch erros when running xml based and java based configs in the same suite Related to #306
The changes allow to build and run the Camunda BPM for a current Wildfly version.
The actual wildfly subsystem won't compile with Wildfy 14 (probably 12 & 13 too), due to changes in the configuration model. This adresses CAM-8934 (https://app.camunda.com/jira/browse/CAM-8934)
I assume the best way would be to have 2 wildfly subsystems, one covering the current supported versions and a second one for the newer Wildfly versions, but this would need more work to be spent in the current maven setup of the project - which I'm not sure if I understood it correctly.
I've built and tested this with Wildfly 14 successfully.