Deploying a WAR on Apache Tomcat
A WAR file is provided for the Apache Tomcat installation that contains
many of the files needed for Magnolia. When the WAR file is deployed,
the files in the WAR file are extracted and placed in the server’s
webapps directory. The remaining directories and files, including the
repositories, are retrieved during the deployment and installation.
Server configuration with
Advanced query filters in the Delivery API require extra Tomcat configuration, namely setting
Tomcat should not be running when executing the following procedure.
To deploy WAR file:
Put WAR file into server’s
Adapt JVM heap size by editing the applicable file in the
/bindirectory in the Apache Tomcat directory:
On Unix, edit
setenv.shfile and add:
export CATALINA_OPTS="-server -Xmx1024m"
On Windows, create
setenv.batfile and add:
set CATALINA_OPTS=-server -Xmx1024m
(Optional) Use headless mode.
When running on a system without a GUI, you should set the
java.awt.headlesssystem property to true.
export CATALINA_OPTS="-server -Xmx1024m -Djava.awt.headless=true"
set CATALINA_OPTS=-server -Xmx1024m-Djava.awt.headless=true
Start Tomcat and wait until it is completely started.
When deploying the Magnolia WAR file Tomcat will need time and heap size to extract the file and bootstrap repositories. Once bootstrapped, Tomcat will not need that much heap anymore.
A directory containing the content of the WAR file and retrieved files is created in the server’s
If you need to configure Tomcat to use virtual hosts, data sources and so on, see the Tomcat Documentation.
Starting with Magnolia 6.2.10, in your Tomcat configuration, make sure that the
does not have the
sameSiteCookies property set to
strict. Instead, set the property to
<CookieProcessor sameSiteCookies="Lax" />
Before Magnolia 6.2.10,
Lax was only supported in setups that do not use HTTPS behind a proxy (MAGNOLIA-8112).
If that is your case, delete the following line from your Tomcat configuration to make sure that
CookieProcessor is not defined:
<CookieProcessor sameSiteCookies="…" />
This approach is less optimal in that there is risk that the effective policy is decided by more recent versions of the browsers themselves, which may lead to unexpected issues.