Magnolia 5.7 reached extended end of life on May 31, 2022. Support for this branch is limited, see End-of-life policy. Please note that to cover the extra maintenance effort, this EEoL period is a paid extension in the life of the branch. Customers who opt for the extended maintenance will need a new license key to run future versions of Magnolia 5.7. If you have any questions or to subscribe to the extended maintenance, please get in touch with your local contact at Magnolia.
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 5.7 requires WildFly 11 or later for compatibility. This page was also verified with JBoss EAP 7.
Preliminaries
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:
- Open
$WILDFLY_HOME/standalone/configuration/standalone.xml
. - Add the following login modules in the
<subsystem
section:xmlns="urn:jboss:domain:security:1.2
>
<subsystem xmlns="urn:jboss:domain:security:1.2"> <security-domains> <security-domain name="magnolia" cache-type="default"> <authentication> <login-module code="info.magnolia.jaas.sp.jcr.JCRAuthenticationModule" flag = "requisite" /> <login-module code="info.magnolia.jaas.sp.jcr.JCRAuthorizationModule" flag = "required" /> </authentication> </security-domain> <security-domain name="Jackrabbit" cache-type="default"> <authentication> <login-module code="org.apache.jackrabbit.core.security.SimpleLoginModule" flag = "required" /> </authentication> </security-domain> <security-domain name="other" cache-type="default"> <authentication> <login-module code="org.apache.jackrabbit.core.security.SimpleLoginModule" flag="required"/> </authentication> </security-domain> </security-domains> </subsystem>
Magnolia Workflow
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.
<?xml version="1.0"?> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"> <deployment> <exclude-subsystems> <subsystem name="weld" /> </exclude-subsystems> </deployment> </jboss-deployment-structure>
Bouncy Castle
Magnolia uses the Bouncy Castle cryptography package to decode the license key and to secure the activation process. WildFly ships with a slightly older version of these libraries.
Find the BC module folder in
$WILDFLY_HOME/modules/system/layers/base/org/bouncycastle/main
.
JBoss EAP
$EAP_HOME/modules/system/layers/base/org/bouncycastle/main
- Remove all the existing jar files.
- Place the required Bouncy Castle JAR files in the folder:
- Provider
bcprov
PKIX
bcpkix
- OpenPGP/BCPG
bcpg
- SMIME
bcmail
- Provider
Edit the
module.xml
file in the same folder.module.xml<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.1" name="org.bouncycastle"> <resources> <resource-root path="bcprov-jdk15on-1.58.jar"/> <resource-root path="bcpkix-jdk15on-1.58.jar"/> <resource-root path="bcpg-jdk15on-1.58.jar"/> <resource-root path="bcmail-jdk15on-1.58.jar"/> </resources> <dependencies> <module name="javax.api" slot="main" export="true"/> </dependencies> </module>
Create or edit
jboss-deployment-structure.xml
file in Magnolia'sWEB-INF
folder by adding the following code.jboss-deployment-structure.xml<?xml version="1.0"?> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"> <deployment> <dependencies> <module name="org.bouncycastle" slot="main" export="true" /> </dependencies> </deployment> </jboss-deployment-structure>
Configuring Log4j
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:
<jboss-deployment-structure> <deployment> <exclusions> <module name="org.apache.log4j" /> <module name="org.slf4j" /> </exclusions> </deployment> </jboss-deployment-structure>
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 jboss-deployment-structure.xml
file:
<exclude-subsystems> <subsystem name="jaxrs" /> <subsystem name="resteasy" /> </exclude-subsystems>
Deployment options
Deploying a WAR
To deploy the downloaded Magnolia WAR file to WildFly:
- Rename the Magnolia WAR file to
magnoliaAuthor.war
. - Make a copy of the file and rename it to
magnoliaPublic.war
. - Copy the files to
$WILDFLY_HOME/standalone/deployments
.
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.
magnolia.home=/somewhere_outside_of_wildfly_tmp_folder magnolia.cache.startdir=${magnolia.home}/cache magnolia.upload.tmpdir=${magnolia.home}/tmp magnolia.exchange.history=${magnolia.home}/history magnolia.repositories.home=${magnolia.home}/repositories magnolia.logs.dir=${magnolia.home}/logs
Deploying extracted directories
To deploy an extracted directory:
- Extract the Magnolia WAR file to the
/magnoliaAuthor.war
directory. - Extract the Magnolia WAR file also to the
/magnoliaPublic.war
directory. - Copy the directories to
$WILDFLY_HOME/standalone/deployments
. - Create empty files
magnoliaAuthor.war.dodeploy
andmagnoliaPublic.war.dodeploy
in the$WILDFLY_HOME/standalone/deployments
directory.
The application server will pick up the extracted directories on startup and will deploy them.
Starting WildFly and accessing Magnolia
- Restart WildFly.
- Access Magnolia Author instance at
http://localhost:8080/magnoliaAuthor/
. - Access Magnolia Public instance at
http://localhost:8080/magnoliaPublic/
.
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.
<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1"> <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" deployment-timeout="120"/> </subsystem>
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 1024m
:
JAVA_OPTS="-Xms64m -Xmx1024m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true"
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
jboss-web.xml
file inWEB-INF
folder of your Magnolia instance. Add the following section in the file. Replace
YourContextPath
with your actual context path which can be/
for a public instance, for example.<jboss-web> <context-root>/YourContextPath</context-root> </jboss-web>
Restart WildFly. Your webapp should be available at
http://localhost:8080/<YourContextPath>
.