Feature request for 7.20: Support WildFly 28

Camunda 7 Topics Discussion & Questions
1

Hey there!

I hope you’re doing well. I wanted to bring up an issue that we recently encountered with WildFly 28 and Camunda 7.19. Unfortunately, it seems that they are currently incompatible. While we understand that compatibility with WildFly 28 was not part of the initial scope, we were still disappointed by this news.

We did encounter an error with the following stack trace:

[org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0002: Error booting the container: java.lang.NoSuchMethodError: 'org.jboss.as.controller.AbstractAttributeDefinitionBuilder org.jboss.as.controller.AbstractAttributeDefinitionBuilder.setAllowNull(boolean)'
	at org.camunda.bpm.wildfly.camunda-wildfly-subsystem@7.19.0//org.camunda.bpm.container.impl.jboss.util.FixedObjectTypeAttributeDefinition$Builder.setAllowNull(FixedObjectTypeAttributeDefinition.java:127)
	at org.camunda.bpm.wildfly.camunda-wildfly-subsystem@7.19.0//org.camunda.bpm.container.impl.jboss.extension.SubsystemAttributeDefinitons.<clinit>(SubsystemAttributeDefinitons.java:142)
	at org.camunda.bpm.wildfly.camunda-wildfly-subsystem@7.19.0//org.camunda.bpm.container.impl.jboss.extension.Attribute.<clinit>(Attribute.java:35)
	at org.camunda.bpm.wildfly.camunda-wildfly-subsystem@7.19.0//org.camunda.bpm.container.impl.jboss.extension.BpmPlatformParser1_1$1.<clinit>(BpmPlatformParser1_1.java:93)
	at org.camunda.bpm.wildfly.camunda-wildfly-subsystem@7.19.0//org.camunda.bpm.container.impl.jboss.extension.BpmPlatformParser1_1.parse(BpmPlatformParser1_1.java:51)
	at org.camunda.bpm.wildfly.camunda-wildfly-subsystem@7.19.0//org.camunda.bpm.container.impl.jboss.extension.BpmPlatformParser1_1$BpmPlatformSubsystemParser.readElement(BpmPlatformParser1_1.java:404)
	at org.camunda.bpm.wildfly.camunda-wildfly-subsystem@7.19.0//org.camunda.bpm.container.impl.jboss.extension.BpmPlatformParser1_1$BpmPlatformSubsystemParser.readElement(BpmPlatformParser1_1.java:377)
	at org.jboss.staxmapper@1.4.0.Final//org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122)
	at org.jboss.staxmapper@1.4.0.Final//org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
	at org.jboss.as.server@20.0.1.Final//org.jboss.as.server.parsing.StandaloneXml_18.parseServerProfile(StandaloneXml_18.java:660)
	at org.jboss.as.server@20.0.1.Final//org.jboss.as.server.parsing.StandaloneXml_18.readServerElement(StandaloneXml_18.java:238)
	at org.jboss.as.server@20.0.1.Final//org.jboss.as.server.parsing.StandaloneXml_18.readElement(StandaloneXml_18.java:139)
	at org.jboss.as.server@20.0.1.Final//org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:132)
	at org.jboss.as.server@20.0.1.Final//org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:52)
	at org.jboss.staxmapper@1.4.0.Final//org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122)
	at org.jboss.staxmapper@1.4.0.Final//org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:76)
	at org.jboss.as.controller@20.0.1.Final//org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:126)
	at org.jboss.as.server@20.0.1.Final//org.jboss.as.server.ServerService.boot(ServerService.java:399)
	at org.jboss.as.controller@20.0.1.Final//org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:471)
	at java.base/java.lang.Thread.run(Thread.java:833)

It seems that the setter setAllowNull() has been removed. Instead, the setRequired(boolean) setter should be used instead. We understand that this setter had been deprecated since 2016, and we’re eager to find a solution.

We kindly request that a fix be released prior to the planned 7.20 release date, if at all possible. Thank you so much for your time and consideration, and we appreciate any assistance you can provide.

2

Hi @mkomko
Thanks for bringing this up.
If it’s something you’re interested in seeing in the next release, please feel free to create feature request here: GitHub - camunda/camunda-bpm-platform: Flexible framework for workflow and decision automation with BPMN and DMN. Integration with Spring, Spring Boot, CDI.

3

Thank you for your reply! I created the following GitHub issue: Support for WildFly 28, 29, 30 · Issue #3368 · camunda/camunda-bpm-platform · GitHub.

It sounds like a fix before the planned 7.20 release date (which, I assume, is October 2023) is out of the question though?

4

It’s likely to first appear in an alpha release before the 2023 October release, but that would only be a few months earlier at most

5

Don’t forget it’s open source, so feel free to help yourself and provide a pull request. We’d be glad to get your contribution :slight_smile:

2 Likes
6

I was thinking about it and if it’s only the small change that I hope it is, I’ll probably do it.

7

Great. I see two increments to this:

  • You just make the minimal code changes to make it work for you with Wildfly 28. As long as that remains compatible with the other versions we support, we should be fine with accepting it. But it wouldn’t mean we support Wildfly 28 officially yet (but a nice preparation for sure)
  • You also update the Wildfly version in our codebase, so that we distribute it and run our CI against it. That would then contribute the full Wildfly 28 support, but would also be more effort.
1 Like
8