We are using Magnolia in a number of projects here at LShift. I have been feeling that Magnolia has a simple way to do most things, but often there are a number of other plausible alternatives that gradually lead you into wasting enormous amounts of time.
Here I want to present a simple way to get both author and public instances of Magnolia running in your dev environment in the same container. It may seem very obvious. If so, good. This was not the first way I tried, and it cost me a lot of time.
We will be aiming for:
- Easily deploying Magnolia onto a stage or production environment — one file, one or two configuration parameters only.
- Making it easy for a tester to launch local public and author instances of Magnolia that talk to each other correctly.
- Making it easy for a developer to debug Magnolia, having both instances running under the control of the IDE.
I will be assuming that you have a parent project with a child project that represents your webapp. I also will assume that you have copied the contents of
src/main/webapp/WEB-INF/config from the
magnolia-empty-webapp project into your own webapp project. The source for this is in the
ce-bundle at git.magnolia-cms.com/gitweb/?p=ce-bundle.pub.git, but assuming you have
magnolia-empty-webapp as a dependency (as recommended) you should be able to pick it up from your
I will be using Tomcat 7 as Tomcat is recommended by Magnolia and 7 is the latest stable version at the time of writing.
Deploying Magnolia to Stage or Production environments
For deployment to stage or production you don’t want both author and public deployed in the same container, or even on the same machine; so we only need to be able to configure a single running instance to be either author or public.
This is quite simple and well documented. In your webapp project, open your
src/main/webapp/WEB-INF/web.xml (that you copied from the empty webapp project as described above) and look for the lines:
You will need to add your own line at the top of the
Then when you deploy your WAR, you can simply set the
instanceName environment variable to
magnoliaAuthor depending on what type of instance you want. As you can see from the fragment of
web.xml above, this will make the settings in
src/main/webapp/WEB-INF/config/magnoliaAuthor/magnolia.properties active, respectively. Ultimately you will want to make more
magnolia.properties files in more subdirectories (called, perhaps,
productionPublic and so on) with appropriate settings for those environments and you can simply make
instanceName refer to the appropriate subdirectory.
Local Magnolia from the command line
Now, it would seem plausible that this method can be made to make your local testing environment work. Plausible, but wrong. This is the difficult way. You’ll start writing your
context.xml files, then you’ll need a
server.xml file, then before you know it you’ll be building your own Tomcat so that you can manage it all.
The “secret” is to use the fact that the
web.xml already refers to the context path, in the form of the line:
(as well as in another line which we won’t concern ourselves with). This means that, instead using an environment variable, you can deploy the same WAR file to two different context paths and Magnolia will set itself up differently for each. And if you choose the paths
/magnoliaPublic you will automatically pick up the properties files provided by the empty webapp and all will be fine — Magnolia even sets up the author instance to point at
http://localhost:8080/magnoliaPublic by default, so you won’t have to configure it yourself!
Well, actually, it’s not all fine. If you try this, you’ll find that one of your instances will refuse to start, complaining that its repository is already locked. Of course, they are trying to use the same repository. Fix this by adding a line similar to the following to
The name of the subdirectory is not important. Note that, as it stands, this will change where the stage and production deployed Magnolias you configured above store their data. If that bothers you, now might be a good time to make your
productionPublic/magnolia.properties and similar files.
So, how do we get that running painlessly so that your tester doesn’t keep asking you how to do it?
Add the Tomcat Maven plugin to your webapp’s
pom.xml, and configure it to launch your WAR twice on two different context paths:
my-webapp with your own webapp’s group and artifact id.
Now you can run your Magnolia simply with:
For reasons best known to the Tomcat plugin, boring old
mvn tomcat7:run doesn’t work — deploying only one Magnolia in its default location. Sorry.
The instances are available, of course, at
Local Magnolia from your IDE
Now you’re on the home straight. Here’s how I configure the Tomcat plugin in Eclipse:
Firstly, you need to get Eclipse to know about Tomcat 7. The foolproof way to do this is as follows: Window -> Preferences -> Server -> Runtime Environments -> Add… -> Apache Tomcat v7.0 -> Next. Now give it a location that is writable by you in the “Tomcat installation directory” box and click “Download and Install…”; using your pre-existing Tomcat might not work if it isn’t laid out in the way Eclipse expects. Now Finish and open the Servers view.
You can now add a new Tomcat 7 server and double-click on it. Tick “Publish module contexts to separate XML files”, set the start timeout to something large like 480 seconds, and in the modules tab add your webapp project twice; once with the path
/magnoliaAuthor and once with the path
Now you can launch and debug your two instances of Magnolia from within your IDE!