How to make Magnolia CMS ready for the Cloud Foundry PaaS – Milestone 1 (Deployment)

Published on February 2, 2016 by Guest blogger

Thomas Ummenhofer is a Data Analyst and Software Engineer at YMC AG since 2013. As part of the Swiss retailer Migros' strategy to operate their software in a modern environment, he is bringing Magnolia to the cloud.


Web applications and services which are developed in 2016 have to be cloud ready. This includes more than deploying them to an 'Infrastructure as a Service' (e.g. at Amazon) instead of a dedicated (virtual) machine. It means that you can deploy your application to a platform which selects and configures the system your application runs on based on the individual needs. This saves time and money for installing and maintaining the infrastructure. Other useful features are health management, scaling and load balancing.

The lack of a fixed binding to a specific machine can be challenging. Not all applications are cloud ready out of the box. More complexity is added by the need for persistent database services or file storage. When your system architecture consists of several interacting applications, as does Magnolia, it can be even more complicated. This article starts a series of blog posts which describe what needs to be done to deploy Magnolia to Pivotal Cloud Foundry.


Standard Magnolia Setup vs. cloud Setup


The following picture shows a standard Magnolia setup. It consists of one Author application and two or more Public applications. Each application stores the content in its own Jackrabbit JCR repository which is usually persisted in a database like MySQL.



How can Magnolia benefit from a platform like Pivotal Cloud Foundry? Of course it is possible to deploy one Author application and two or more Public applications to Cloud Foundry. Just like a normal Magnolia setup, only using a different infrastructure. So what’s the benefit? You don’t have to bother about the maintenance of the Magnolia infrastructure. That’s good, but not good enough. A much larger benefit would be if horizontal scaling is as easy as adding a new instance to a single Public application. No need for an additional Cloud Foundry application, no need for configuring a new environment in Magnolia’s single WAR deployment, no need for setting up a new database service, no need for importing a content dump and no need for subscriber registration.


Sounds great! Such a setup looks like this:



This overall goal can be split into several milestones. The first milestone, deploying Magnolia to Cloud Foundry, is covered in the rest of this article. Following topics like persisting the data or making the Public application scalable will be handled in upcoming blog posts.


Milestone 1: Deploying Magnolia to the Cloud


Application-specific Magnolia configuration 


Magnolia allows a single WAR deployment, meaning that Author and Public Cloud Foundry Web Applications use the same WAR file and only differ by configuration. The configuration can amongst others depend on environment variables, the server name, or the context path. This mechanism is configured in the context parameter magnolia.initialization.file in web.xml. Since we want to deploy all our applications to the ROOT context and have no control over which server the application runs on, it is a good idea to use an environment variable; let’s call it  magnoliaInstanceType for context loading. This can be reached in  web.xml with the following context parameter:









This allows us to place different property files in WEB-INF/config/ to configure different Cloud Foundry Applications. Since we want to deploy two applications, one for Magnolia Author and one for Magnolia Public, we need to create two property files, let’s and, which will be loaded depending on the environment variable magnoliaInstanceType.


Environment variables in Cloud Foundry can be set in the application specific manifest.yml. The cfauthor-manifest.yml contains the following property:


  magnoliaInstanceType: cfauthor


The cfpublic-manifest.yml works likewise.


Jackrabbit Configuration


The most important configuration for running Magnolia in the cloud is the one for Jackrabbit JCR. Since our first goal is just to get Magnolia up and running and not to get a persistent application, we can use the default Derby persistence manager which uses the file system. But as the file system on Cloud Foundry is elusive anyway and won’t survive rebooting, we can also use an in-memory database to speed up the system. This is done by pointing the Magnolia property magnolia.repositories.jackrabbit.config to the following file:


<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE Repository PUBLIC "-//The Apache Software Foundation//DTD Jackrabbit 2.0//EN" "">


  TESTING-ONLY configuration!

  repositories are in memory only and any change is lost upon restart



  <FileSystem class="org.apache.jackrabbit.core.fs.mem.MemoryFileSystem" />

  <Security appName="magnolia">

    <SecurityManager class="org.apache.jackrabbit.core.DefaultSecurityManager"/>

    <AccessManager class="">


    <!-- login module defined here is used by the repo to authenticate every request. not by the webapp to authenticate user against the webapp context (this one has to be passed before thing here gets invoked -->

    <LoginModule class="info.magnolia.jaas.sp.jcr.JackrabbitAuthenticationModule">



  <Workspaces rootPath="{rep.home}/workspaces" defaultWorkspace="default" />

  <Workspace name="default">

    <FileSystem class="org.apache.jackrabbit.core.fs.mem.MemoryFileSystem" />

    <PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.BundleFsPersistenceManager">

      <param name="blobFSBlockSize" value="1" /><!-- store in memory -->


    <SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">

      <param name="path" value="${wsp.home}/index" />

      <!-- SearchIndex will get the indexing configuration from the classpath, if not found in the workspace home -->

      <param name="indexingConfiguration" value="/info/magnolia/jackrabbit/indexing_configuration.xml"/>

      <param name="useCompoundFile" value="true" />

      <param name="minMergeDocs" value="100" />

      <param name="volatileIdleTime" value="3" />

      <param name="maxMergeDocs" value="100000" />

      <param name="mergeFactor" value="10" />

      <param name="maxFieldLength" value="10000" />

      <param name="bufferSize" value="10" />

      <param name="cacheSize" value="1000" />

      <param name="forceConsistencyCheck" value="false" />

      <param name="autoRepair" value="true" />

      <param name="queryClass" value="org.apache.jackrabbit.core.query.QueryImpl" />

      <param name="respectDocumentOrder" value="true" />

      <param name="resultFetchSize" value="100" />

      <param name="extractorPoolSize" value="3" />

      <param name="extractorTimeout" value="100" />

      <param name="extractorBackLogSize" value="100" />



      <AccessControlProvider class="info.magnolia.cms.core.MagnoliaAccessProvider" />



  <Versioning rootPath="${rep.home}/version">

    <FileSystem class="org.apache.jackrabbit.core.fs.mem.MemoryFileSystem" />

    <PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.BundleFsPersistenceManager">

      <param name="blobFSBlockSize" value="1" /><!-- store in memory -->





While using an in-memory database, the configuration for Author and Public can point to the same Jackrabbit JCR configuration. As soon as external services are used for persistence, different configuration is required.


Cloud Foundry Deployment


Like this, the applications can be deployed to Pivotal Cloud Foundry using cf push -f cfauthor-manifest.yml or  cf push -f cfpublic-manifest.yml. The following shows a complete Cloud Foundry Manifest for the Author:


path: webapp/target/magnolia-app.war

timeout: 180

memory: 2G

instances: 1



  magnoliaInstanceType: cfauthor



  - name: mgnl-author


The only thing worth mentioning here is the timeout, which is increased from the default 60 seconds to 180 seconds because Magnolia might take longer to startup, especially for the initial installation process (which in our case is performed on each startup since there is no persistence).


Automatic Subscriber Configuration


To make working with Cloud Foundry more comfortable, there is a Magnolia Cloud Foundry Module. This adds some nice features like handling of Cloud Foundry services (which will be covered in an upcoming blog post) or setting up the activation process. When this module is added, the Public application can automatically be configured as a subscriber by passing it as an environment variable to the Author.



  magnoliaPublicInstanceURI: ''


That’s it. Magnolia can be pushed to the cloud. Even the content activation is already working. Just make sure you never restart one of the two apps, otherwise all of its data is gone.

Read about other issues can be solved in the next article of this series here. Also published at


Thomas Ummenhofer, YMC AG


Thomas Ummenhofer is Data Analyst and Software Engineer at YMC AG since 2013. Besides his passion for analyzing large amounts of data, he also develops reliable and scalable software solutions. As part of the Swiss retailer Migros' strategy to operate their software in a modern environment, he is bringing Magnolia to the cloud.



{{item.userId}}   {{item.timestamp | timestampToDate}}

About the author Guest blogger

Magnolia has an amazing community of partners and clients, among them quite a few wordsmiths. From time to time, they put their expertise into blog posts and share them on this platform.

See all posts on Guest blogger