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.

Magnolia CORE 5.7 introduces new data privacy features making us a GDPR-friendly CMS. We help you manage personal data, track website visitor consent, facilitate data portability and ensure your visitors' right to be forgotten. 

Developers can create templates and apps faster than ever with the new simplified field type names. Now you can supply a short, easy-to-remember field type name instead of a long Java class name.

Magnolia CORE 5.7 also brings many technical updates such as runtime compatibility with Java 9 and Java 10, upgrade of Java specification baseline to Java EE 8, upgrade of Vaadin to version 8.4.2, Apache Jackrabbit to version 2.16.1, Freemarker to 2.3.38 and others.

Changes for authors

Data privacy features

This release focuses on equipping Magnolia with the tools you require to protect your users' personal data and privacy. With GDPR in force since May 25, 2018, we deliver functionality to help you make your websites compliant:

For an overview of the functionality available, read Data privacy.


Faster browsing with very large numbers of assets

Assets in the Magnolia DAM can now be indexed using Apache Solr, making the tree and list views in the Asset apps much faster to use. With 200,000 assets, search results are returned on average under 2 seconds. The tree and list views perform robustly when you browse assets.

Solr search works better than the default Jackrabbit search for large numbers of assets. While Jackrabbit can comfortably handle a small number of nodes, like we have in the config workspace, it was not designed for indexing massive numbers of nodes. 

You can replace the default search container with the Solr-based container with configuration

Using Apache Solr in the Assets app requires Magnolia Solr module version 5.2.


XML export action offers a download dialog

This release fixes an issue occurring in Magnolia 5.6.6 where exporting an XML bootstrap file opens the file directly in the active browser window instead of offering a download dialog. The issue does not appear for YAML format exports.


Changes for developers

Referencing field types by name

Developers can create templates and apps faster, because it’s now easier to specify the fields in a form. Instead of searching for and specifying a fully qualified class name of a field, you can now provide just its name as a value of a new property called fieldType

You can now add a text field to a form with just fieldType: text

    - name: tabText
        - name: title
          fieldType: text

Previously the field required a fully-qualified class name:

    - name: tabText
        - name: title
          class: info.magnolia.ui.form.field.definition.TextFieldDefinition

The feature is backwards compatible, you may still supply a class property, or you can use the new fieldType property.

Commonly used fields have been renamed to make them consistent and easy to remember. For example, textField was renamed to text. To view the field names, look in the Definitions app:

Not all Magnolia modules (for example MTE and Travel Demo) use this new convention yet, but over time all our modules will. For a list of the names that have been changed see the Upgrading to Magnolia 5.7.x page.


Upgrade to Java EE 8

The baseline for Java enterprise feature specification in this release is Java EE 8, which is also the baseline of the Jakarta EE project.

With Java EE 8 in place, Magnolia developers will benefit especially from:

  • JSR 370 – Java API for RESTful Web Services (JAX-RS) 2.1, bringing:
    • Support for Server Sent Events (server and client)
    • JSON Binding (JSON-B) API integration
    • New Reactive client API
  • JSR 367 – Java API for JSON Binding (JSON-B), which you can add to and test-try with Magnolia.


Java 9 and Java 10 runtime compatibility

With this release, Magnolia is runtime compatible with Java 9 and Java 10.


If you want to build Magnolia yourself, you must use Java 8.
Enabling compilation with Java 9 and Java 10 is next:  BUILD-303 - Getting issue details... STATUS .

Form module fully adopts the i18n mechanism

In the Form module's dialogs and components we removed the i18nBasename  property in favor of the new i18n mechanism that relies on message bundles.

We have removed all instances of the following properties from the /modules/form/dialogs and /modules/form/templates/components subtrees:

  • title
  • label
  • description
  • buttonLabel
  • leftColumnCaption
  • rightColumnCaption

Magnolia i18n API generates these keys automatically and defining their values in a message bundle makes it is much easier for translators to locate texts for translation.


Dynamically defined dialog names

This release introduces a new property called dialogLabelItemProperty. It allows you to set a dialog's name via a property holding the preferred value for the dialog caption, for example via the jcrName property. If no dialogLabelItemProperty is configured for the dialog, Magnolia tries to retrieve the dialog's name from the language bundle associated with the dialog.

You can see the new property implemented in the Security app dialogs for example. 

In Magnolia 5.7, the new dialogLabelItemProperty property is set:

As a result, the dialog's caption now shows eric which is the value of the jcrName property for the dialog:

For comparison, here's the same dialog in older Magnolia 5.6.6, where the property is not available and the "User" caption of the dialog is defined with security-app.user.label=User in the app's language bundle:


Third-party library updates

This release comes with many updates of third-party libraries

  • Vaadin 8.4.2
    • vaadin-compatibility-aceeditor-1.0
    • vaadin-compatibility-ckeditor-1.0
    • vaadin-compatibility-client-8.4.2
    • vaadin-compatibility-context-menu-1.0
    • vaadin-compatibility-expandingtextarea-1.0
    • vaadin-compatibility-server-8.4.2
    • vaadin-compatibility-shared-8.4.2
    • vaadin-compatibility-themes-8.4.2
    • vaadin-compatibility-tokenfield-1.0
    • vaadin-server-8.4.2
    • vaadin-shared-8.4.2
    • validation-api-1.1.0.Final
  • Apache Jackrabbit 2.16.1
    • jackrabbit-api-2.16.1
    • jackrabbit-core-2.16.1
    • jackrabbit-data-2.16.1
    • jackrabbit-jcr-commons-2.16.1
    • jackrabbit-spi-2.16.1
    • jackrabbit-spi-commons-2.16.1
  • FreeMarker  2.3.28
  • Apache Groovy 2.5

The Apache Groovy update prompted us to upgrade our Groovy module to version 2.7. Note that the module now ships only with a minimal set of required libraries:

    • groovy-2.5.0.jar
    • groovy-xml-2.5.0.jar

Some of your custom Groovy scripts may require additional libraries.

Other libraries:

  • commons-lang3-3.7
  • freemarker-2.3.38
  • gson-2.2.2
  • guice-4.2.0
  • guice-multibindings-4.2.0
  • jackson-databind-2.9.5
  • jsoup-1.8.3
  • mycila-guice-closeable-4.0
  • mycila-guice-injection-4.0
  • mycila-guice-jsr-4.0
  • snakeyaml-1.21

We also removed Apache Xerces (xercesImpl) due to the fact that Java (since Java SE 7) already contains Java API for XML Processing (JAXP).

For more details, see the list on the Upgrading to Magnolia 5.7.x page and check the BOM for third-party modules in Magnolia 5.7.


Apache Tomcat updated

In the bundles we have upgraded Apache Tomcat to version 9.0.8


WebDAV deprecated

Magnolia WebDAV module is now deprecated. The purpose of the module was to access the Magnolia repository through the WebDAV API, typically allowing users to edit resources and templates on the file system. Technology used in the module is obsolete: the WebDAV module depends on an old HttpClient 3.x library which has reached end of life; and Jackrabbit 2.16 removed the HttpClient3-based WebDAV API completely on May 16, 2018.

Deprecation means that we stop bundling the WebDAV module with the product. You can still get the code from our Nexus repository but we don't recommend using it anymore. The deprecated status lasts for one year. On June 20, 2019 we will remove the module from the product completely and donate it to the community on the Magnolia Forge. Latest documentation for the WebDAV module is available in the Magnolia 5.6 documentation space on the WebDAV module page only until the end of support of the 5.6 branch.

See the WebDAV deprecation section on the Upgrading to Magnolia 5.7.x page where we describe WebDAV module use cases and more modern ways to do the same thing.

DMS workspace removed

The dms workspace was a Magnolia repository for storing assets uploaded to the Document Management System. Since the system was phased out with the release of Magnolia 5 and the workspace's function replaced with a much more flexible dam repository, all the remaining parts of the dms workspace have been removed from the 5.7 branch.

Read How to delete a JCR workspace, if you are upgrading from an earlier version and want to remove the dms workspace.


Deprecated modules removed from the add-ons bundle

The following deprecated modules are no longer included in the Magnolia Enterprise add-ons bundle:

  • magnolia-jndi-1.0.2
  • magnolia-module-newsletter-bundle-2.2
  • magnolia-module-webdav-2.1.3
  • magnolia-templating-samples-5.4.1


Security vulnerabilities fixed

We have fixed several security issues with this release. We keep details of this kind of fix private in line with our Security PolicyContact our Support team if you need more information.

MGNLPN-422, MGNLUI-4458 ((warning) restricted access)


If you are upgrading from an earlier version, read the Upgrading to Magnolia 5.7.x page first and check the Known issues section on it.


See the 5.7 changelog for all the changes. 

Updated modules

  • Advanced Cache 2.0
  • Backup 2.3
  • Barebones Magnolia Tomcat Bundle 1.1
  • Community Edition 5.7
  • Content Dependencies 1.9
  • Content Editor 1.2
  • Content Tags 1.1
  • DAM 2.4
  • Demo Projects 1.3
  • Diff 2.1
  • Enterprise Edition 5.7
  • Form 2.5
  • Groovy 2.7
  • Imaging 3.4.1
  • Magnolia 5.7
  • Marketing Tags Manager 1.4
  • Pages 5.7
  • Personalization 1.6
  • Privacy 1.0
  • Publishing 1.0.5
  • Templating Essentials 1.2.2
  • Third-party library BOM 5.7
  • UI 5.7

Post-release recommended update

Log Tools 1.1 contains a security risk

Magnolia 5.7 bundles Magnolia Log Tools version 1.1 that contains a security risk.

We strongly recommend you upgrade your webapp or bundle with Log Tools 1.1.1 (already released).

  • Jar file: 

    Error rendering macro 'artifact-resource-macro'

    com.sun.jersey.api.client.ClientHandlerException: A message body reader for Java class, and Java type class, and MIME media type application/octet-stream was not found

  • Error rendering macro 'artifact-maven-dependencies-snippet-macro'

    com.sun.jersey.api.client.ClientHandlerException: A message body reader for Java class, and Java type class, and MIME media type application/octet-stream was not found


The Magnolia team would also like to thank everyone who reported issues, contributed patches, or simply commented on issues for this release. Your continued interest helps us make Magnolia better. Special thanks go to: Nils Breunese, Arne Diekmann, Gernot Fussan, Rico Jansen, Daniel Lipp, Michiel Meeuwissen and Tom Wespi.

  • No labels


  1. Webdav is very useful tool for us, Jackrabbit still support webdav, you can find the latest version in maven, and it's just updated to httpclient4, I can find httpclient-4.5.3.jar in magnolia 5.7 bundle. So why it doesn't support any more, unreasonable.

    1. Hi Ming Yin, I'm sorry to hear that ending support for the WebDAV module is inconvenient for you. Here's the background.

      The Magnolia WebDAV module depends on HttpClient 3.x code. Jackrabbit 2.16 removed the HttpClient3 based WebDAV API and introduced a completely new WebDAV API.  We had to evaluate whether it makes sense to rewrite our WebDAV module for the new API or offer other ways to do typical WebDAV tasks. We chose not to rewrite the module and recommend light development instead.

      You can do many common WebDAV tasks with light development. You can store web resources such as CSS and JS files, template scripts and many more items in a light module and edit them comfortably as local files with your favorite editor. When you are done with the changes, push and commit the files to Git and configure Magnolia to watch for changes in the remote Git directory. Magnolia will register changes in light modules instantly.

      Can you share your WebDAV use case? How are you using the module? Also, would you be interested in updating the module to the new set of APIs based on HttpClient 4.5.x if we donated the module to the Magnolia community right now?

    2. Hello Ming Yin,

      For the short of Jackrabbit webdav at the moment, we've tried to make use of Apache Tomcat Webdav (which is a built-in function of this container) using few integration configuration points here Integration with Tomcat Webdav. Could you please use it for your interest.

      Please carefully configure security points based on your needs and please contact Support in case of any concerns.

      Note that Tomcat Webdav just give you a way to interact with file system while Magnolia already provided you with almost all JCR related control via JCR browser app. This might also lead to the deprecation of Jackrabbit webdav module.

    3. Sorry for being a little late to the party here. I do understand the webdav can still be useful. I did update the module for 6.2 if you'd still like to use it. See

  2. Hi Antti Hietala,

    Our case is that we store the web resources in JCR workspace, the deployment team use webdav manage the resources.

  3. If the installation process is very slow, it's possible you might have to add `` to the startup flags.

    The H2 persistence manager performs a lot of calls to `` and `` which cause massive slow downs if there is no/or a broken IPv6 nameserver available.

    1. Thanks Ronald Ten Berge, I believe it can also be fixed through /etc/hosts, see

      1. I've checked but Windows seems to handle the DNS resolution differently, so for Windows I still have to add the startup flag.