From version < 27.1 >
edited by Vincent Massol
on 2018/09/06
To version < 27.2 >
edited by Vincent Massol
on 2019/07/09
< >
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -2,16 +2,14 @@
2 2  {{toc/}}
3 3  {{/box}}
4 4  
5 += WildFly 17.x =
6 +
7 +The instructions are the same as for Wildly 14.x below.
8 +
5 5  = WildFly 14.x =
6 6  
7 7  The instructions are the same as for Wildly 10.x below.
8 8  
9 -Note that the following issues were fixed in XWiki 10.8RC1/10.8 to make XWiki deploy fine on WildFly 14.x:
10 -
11 -{{jira url="https://jira.xwiki.org" source="jql" style="list"}}
12 -project = "XWiki Platform" and fixVersion in (10.8-rc-1, 10.8) and resolution = Fixed and labels in (wildfly)
13 -{{/jira}}
14 -
15 15  = WildFly 10.x =
16 16  
17 17  The instructions are the same as for JBoss AS 7.x below.
... ... @@ -24,10 +24,12 @@
24 24  
25 25  === Weld Deployment Error ===
26 26  
27 -WildFly does automatic implicit CDI deployment when it finds some CDI beans in JARs. We need to prevent this since XWiki doesn't use CDI and there can be some third-party deps we use that have some CDI annotations. This is [[fixed>>https://jira.xwiki.org/browse/XWIKI-13678]] but if you encounter it, see [[Implicit module dependencies for deployments>>https://docs.jboss.org/author/display/WFLY10/Implicit+module+dependencies+for+deployments]] to prevent it.
25 +WildFly does automatic implicit CDI deployment when it finds some CDI beans in JARs. We need to prevent this since XWiki doesn't use CDI and there can be some third-party deps we use that have some CDI annotations.
28 28  
29 -Also, starting with XWiki 10.8RC1 we've removed the fix since [[WildFly 14 chokes on it>>https://jira.xwiki.org/browse/XWIKI-15566]]. Thus if you need to deploy some oldish version of WildFly on newer versions of XWiki you could add a META-INF/jboss-all.xml file containing:
27 +Note that we [[fixed this>>https://jira.xwiki.org/browse/XWIKI-13678]] by providing a ##META-INF/jboss-all.xml## file telling WildFly to not do CDI bean scanning in XWiki 8.3M2+. However [[we found a problem with it and removed it>>https://jira.xwiki.org/browse/XWIKI-15566]] in XWiki 10.8RC1+. In the end, it was found that [[this file was needed after all>>https://jira.xwiki.org/browse/XWIKI-16577]] and put back in XWiki 10.11.9/11.3.2/11.6RC1+...
30 30  
29 +If you're using a version of XWiki that doesn't provide this ##jboss-all.xml## then create one in the ##META-INF## directory inside the XWiki WAR, with the following content:
30 +
31 31  {{code language="xml"}}
32 32  <?xml version="1.0" encoding="UTF-8"?>
33 33  

WildFly 14.x

WildFly 17.x

The instructions are the same as for Wildly 10.x below.

The instructions are the same as for Wildly 14.x below.

Note that the following issues were fixed in XWiki 10.8RC1/10.8 to make XWiki deploy fine on WildFly 14.x:

WildFly 10.x

WildFly 14.x

The instructions are the same as for JBoss AS 7.x below.

The instructions are the same as for Wildly 10.x below.

WildFly 10.x

The instructions are the same as for JBoss AS 7.x below.

Some documentation that can be useful:

Troubleshooting

Weld Deployment Error

WildFly does automatic implicit CDI deployment when it finds some CDI beans in JARs. We need to prevent this since XWiki doesn't use CDI and there can be some third-party deps we use that have some CDI annotations. This is fixed but if you encounter it, see Implicit module dependencies for deployments to prevent it.

WildFly does automatic implicit CDI deployment when it finds some CDI beans in JARs. We need to prevent this since XWiki doesn't use CDI and there can be some third-party deps we use that have some CDI annotations.

Also, starting with XWiki 10.8RC1 we've removed the fix since WildFly 14 chokes on it. Thus if you need to deploy some oldish version of WildFly on newer versions of XWiki you could add a META-INF/jboss-all.xml file containing:

Note that we fixed this by providing a META-INF/jboss-all.xml file telling WildFly to not do CDI bean scanning in XWiki 8.3M2+. However we found a problem with it and removed it in XWiki 10.8RC1+. In the end, it was found that this file was needed after all and put back in XWiki 10.11.9/11.3.2/11.6RC1+...

If you're using a version of XWiki that doesn't provide this jboss-all.xml then create one in the META-INF directory inside the XWiki WAR, with the following content:






xmlns="urn:jboss:1.0">
  xmlns="urn:jboss:weld:1.0" require-bean-descriptor="true"/>

JBoss AS 7.x

Example using Standalone Deployment

  • Copy the xwiki expanded WAR directory in JBOSSHOME/standalone/deployments/xwiki.war
  • Do a touch JBOSSHOME/standalone/deployments/xwiki.war.dodeploy
  • Start JBoss standalone: run ./standalone.sh from JBOSSHOME/bin/

Troubleshooting

"More than the maximum number of request parameters" error

If you get the following error in the logs when trying to import a large XAR:

Servlet.service() for servlet action threw exception: java.lang.IllegalStateException: More than the maximum number of request parameters (GET plus POST) for a single request ([512]) were detected. Any parameters beyond this limit have been ignored. To change this limit, set the maxParameterCount attribute on the Connector.

You'll need to configure Tomcat in JBoss to support more than 512 form fields.

JBoss AS 4.0.x

  • Download and install the "JBoss Application Server". It's usually as simple as unzipping it in a directory. Let's call this directory $JBOSS_HOME
  • (optional) By default JBoss runs on port 8080. If you want to modify the port on which JBoss is running, edit $JBOSS_HOME/server//deploy/jbossweb-tomcat55.sar/server.xml. Search for 8080 and replace it with the port value you wish to use. Similarly change the port in $JBOSS_HOME/server//deploy/http-invoker.sar/META-INF/jboss-service.xml to the value you like
  • Copy and expand the XWiki WAR into a directory named xwiki.war/ (note that unlike most servlet containers JBoss wants the directory name to end with .war) in $JBOSS_HOME/server//deploy where server configuration is the JBoss configuration you're using
  • Edit $JBOSS_HOME/server//deploy/jbossweb-tomcat55.sar/server.xml to set UTF-8 encoding:
    <Connector port="8080" ... URIEncoding="UTF-8"/>
    <Connector port="8009" ... URIEncoding="UTF-8"/>

Classloading Isolation

The default JBoss behavior is that classes inside of the WEB-INF/classes and WEB-INF/lib directories of the WAR file are incorporated into the default shared class loader repository. This allows classes and resources to be shared between web applications. However this means that JARs provided by XWiki in WEB-INF/lib will get mixed with JARs provided by JBoss and if both application provide the same JAR but in a different version, class incompatibilities will occur. 

To solve this please read up on JBoss ClassLoading Configuration in order to configure JBoss not to use the unified class loader (set UseJBossWebLoader to false in META-INF/jboss-service.xml).

Alternatively you may try to remove the clashing JARs from XWiki's WEB-INF/lib hoping that the version provided by JBoss is compatible with XWiki's needs.

Log4j Error

It was reported that with XWiki 1.6 and JBoss 4.0.4, using these settings would generate an error with hibernate. Everything seems to work fine without these settings including classloading of log4j.

  • Edit $JBOSS_HOME/server//jbossweb-tomcat55.sar/META-INF/jboss-service.xml file and replace:
    name="Java2ClassLoadingCompliance">false
    name="UseJBossWebLoader">false
    with:
    name="Java2ClassLoadingCompliance">true
    name="UseJBossWebLoader">true
    This is to avoid class loading issues for the Log4J library.

Using a JBoss DataSource

JBoss links about this topic:

Tutorial for JBoss AS 7.1

  • Create a JBoss Module for your database driver. For example for HSQLDB, create the directory [ASROOT]/modules/org/hsqldb/main and put the HSQLDB Driver JAR (e.g. hsqldb-2.2.9.jar) in it and also create a module.xml in it and write the following code inside:

    xmlns="urn:jboss:module:1.0" name="org.hsqldb">
     
        path="hsqldb-2.2.9.jar"/>
     
     
        name="javax.api"/>
     
  • Create a data source file named -ds.xml (e.g. hsqldb-ds.xml). If you're using a standalone deployment, put it in [ASROOT]/standalone/deployments/ (you can also put it in your WEB-INF/ dir). Example of content:

    xmlns="http://www.jboss.org/ironjacamar/schema">
      jndi-name="java:jboss/datasources/XWikiDS" pool-name="XWikiDS" enabled="true" use-java-context="true">
       jdbc:hsqldb:file:[path to your hsqldb db file, e.g. /tmp/xwiki-data/database/xwiki_db];shutdown=true
       hsqldb
       
         sa
         
       
     

Old Tutorial

  • Uncomment the resource-ref section in XWiki's web.xml file. You should have:

     DB Connection
     jdbc/XWikiDS
     javax.sql.DataSource
     Container
  • Create the following jboss-web.xml file in the deployed XWiki's WEB-INF/ directory:



     
           jdbc/XWikiDS
           java:jboss/datasources/XWikiDS
      
  • Modify XWiki's WEB-INF/hibernate.cfg.xml file to tell Hibernate to use the defined DataSource rather than a direct JDBC connection:
    ...
    name="connection.datasource">java:jboss/datasources/XWikiDS
    ...

Issues related to JBoss

Get Connected