We are currently evaluating the integration of XWiki into our Java-based Jakarta EE application, which runs on WildFly 34. According to the Admin Guide, it appears that WildFly 27+ is not yet supported.
Q1: Is there a planned timeline for supporting Jakarta EE 10?
In my opinion, the the easiest way to integrate XWiki would be to overlay the artifact xwiki-platform-distribution-war with our existing WAR module before packaging it into an EAR along with our other modules. Since we are using CDI for dependency injection, and XWiki uses its own mechanism, this overlay approach might lead to conflicts. This makes me think that we might need to create a separate WAR module within our EAR.
Q2: I read that
The future will depend on whether there’ll be a standard solution in Java SE (CDI is the best candidate so far). When a standard solution exists, we’ll probably move to it.
Since CDI is already the standard solution for dependency injection in Jakarta EE, do you have any plans to support CDI in XWiki, regardless of whether it becomes a standard in Java SE? If so, is there a timeline for this?
If your main concern is related to the javax vs jakarta mess (so Jakarta EE 9) then XWiki moved to Jakarta EE 9.1 in 17.0.0 (the current branch). The XWiki LTS branch is still based on EE 8 (and that will not change) so you cannot use that one. But I don’t except that using an application built for Jakarta EE 9.1 in a Jakarta EE 10 application server would be a problem (AFAIK XWiki 17.x works fine with both Tomcat 10.1 and Tomcat 11, for example).
Not sure why this would cause conflicts. I assume this would just means that you have two component worlds which don’t talk to each other. We already have this situation with Jersey and Solr, which are using CDI (through HK2), and we did not notice any conflict with XWiki components.
Yes, exactly. Ideally, we want to avoid having two WARs in our EAR. The XWiki WAR only functions correctly if the module does not contain a beans.xml file due to the provided jboss-all.xml configuration:
<!-- Required to tell WildFly to not do CDI bean parsing and implicit deployment
since XWiki doesn't use CDI -->
<jboss xmlns="urn:jboss:1.0">
<weld xmlns="urn:jboss:weld:1.0" require-bean-descriptor="true"/>
</jboss>
This configuration explicitly prevents WildFly from performing CDI bean parsing and automatic deployment, as XWiki does not rely on CDI.
If there is a known solution or workaround for this issue, we would greatly appreciate any guidance on how to resolve this behavior.