This page describes how to deploy Magnolia as a WAR file on WildFly, formerly known as JBoss Application Server. The procedures described below have been checked for WildFly 11+. Magnolia 6.1 requires WildFly 11 or later for compatibility. This page was also verified with JBoss EAP 7.
magnolia-dx-core-wildfly-webapp works for both WildFly and EAP distributions.
Configuring JAAS login
Magnolia uses the Java Authentication and Authorization Service (JAAS) to authenticate and authorize users. You have to configure the JAAS login modules for WildFly so that you can log into Magnolia:
Add the following login modules in the
<subsystem xmlns="urn:jboss:domain:security:2.0>section. Whichever you have.
When using Magnolia's worklow modules you might experience class loading issue related to packages of
org.jboss.weld.*. In this case create or edit
jboss-deployment-structure.xml file in Magnolia's
WEB-INF folder by adding the following code.
Find the BC module folder in
- Remove all the existing JAR files.
Place the required Bouncy Castle JAR files in the folder:
Here you can download a copy of the entire bouncycastle folder as it should be setup.
module.xmlfile in the same folder.
Create or edit
jboss-deployment-structure.xmlfile in Magnolia's
WEB-INFfolder by adding the following code.
WildFly Application Server adds its own log4j logging configuration. If you want to use your own log4j logging configuration (or the one provided by Magnolia) in your deployment, exclude the default configuration first.
Create a new file
jboss-deployment-structure.xml under the
WEB-INF folder with this content:
Resteasy class loading issue
During a deployment the Resteasy libraries can cause a class loading issue when the RestClient module is used. You can get rid of the issue by excluding the following subsystems in the
<deploymenŧ> element of the
Deploying a WAR
To deploy the downloaded Magnolia WAR file to WildFly:
- Rename the Magnolia WAR file to
- Make a copy of the file and rename it to
- Copy the files to
The application server will automatically pick up the files and deploy them.
WildFly unpacks .war files to a
tmp directory and deletes the directory as part of the shutdown process. This means that every time WildFly restarts, the Magnolia webapp forgets everything – modules, repository, license key. To get around this issue, you can deploy the Magnolia webapp as an extracted (unpacked) directory or configure Magnolia to store the repository outside the
tmp directory. Alternatively, specify the following paths in your
magnolia.properties configuration. If you point the paths outside of WildFly's
tmp directory, Magnolia will not reinstall on every startup and they will not be deleted on every shutdown.
Deploying extracted directories
To deploy an extracted directory:
- Extract the Magnolia WAR file to the
- Extract the Magnolia WAR file also to the
- If you did not download the prebundled WildFly webapp, set the
- Copy the directories to
- Create empty files
The application server will pick up the extracted directories on startup and will deploy them.
Starting WildFly and accessing Magnolia
It may happen that the Magnolia application is not deployed because of deployment timeout. You can avoid this by setting the
deployment-timeout parameter to higher value in
$WILDFLY_HOME/standalone/configuration/standalone.xml. The default is 60 seconds.
If you experience
java.lang.OutOfMemoryError when accessing Magnolia instances, try restarting WildFly with the JVM
Xmx value in
$WILDFLY_HOME/bin/standalone.conf set at least to
Changing the context path
Without the WAR file placed under
WEB-INF folder, the context path will be the web application's folder name by default.
- Stop WildFly.
- Create a
WEB-INFfolder of your Magnolia instance.
Add the following section in the file. Replace
YourContextPathwith your actual context path which can be
/for a public instance, for example.
Restart WildFly. Your webapp should be available at