This documentation refers to Groovy module 2.2 and greater. The Groovy module is compatible with Magnolia 5 starting from version 2.0. If you are using Groovy module before 2.2, see Groovy module in Magnolia 4.5.
The module uses Groovy language 2.1.8
Magnolia Groovy module adds Groovy capabilities to Magnolia. Groovy is a popular dynamic language for the JVM. To know more about it, please visit the Groovy official website which has plenty of tutorials and excellent documentation both for beginners and advanced users of the language. The module provides a web based Unix-like console where you can access contents in Magnolia repositories in a "groovish" way, a
scripts repository where you can store your scripts and the ability to plugin Groovy classes into Magnolia at runtime, without the need for deploying them and restarting the servlet container. All these tools make for a more agile approach to coding and maintaining Magnolia based websites.
The Groovy module is bundled with Magnolia and typically already installed. You can download it from our Nexus repository.
Groovy is a Community Edition module. It is typically already installed. Launch the Configuration app and go to
/modules/groovy to check.
Create a backup of your system before you install a module. Uninstalling a module is not as simple as removing the .jar file. Modules add and change configurations and may change the content. Try new modules in a test environment first. A module consists of a JAR file and may include dependent JAR files. Modules are responsible for updating their own content and configurations across versions. Be sure to keep only one version of each module and its dependencies.
To install a module:
- Stop the application server.
- Copy the module JAR files into the
WEB-INF/libdirectory. The location of this directory depends on the application server.
- Restart the server.
- Go to the AdminCentral URL.
- Start the Web update process.
- Click Start up Magnolia.
Repeat the steps for each author and public instance.
To uninstall a module, remove the module JAR file from the
/WEB-INF/lib folder and restart Magnolia.
However, this is rarely enough. Modules add and modify configuration during installation. The use of a module also changes content. Removing all of these changes is difficult without knowing the installation tasks in detail.
To test a module, use the embedded Derby database and take a backup of your
repositories folder. Install the module and try it. When you are done testing, remove the module JAR and restore the
repositories folder from the backup. This way you can go back to square one.
We also recommend that you segregate the development and production environments. Take regular backups for disaster recovery so you can revert to a prior state in a routine fashion.
Repository data navigation simplified
Thanks to the .(dot) notation and other handy shortcuts such as
.parent you can read any content node and property, change their values, create nodes and delete them, all with clean, concise syntax. The module is shipped with some preinstalled scripts that demonstrate most of these features. As an example, here is how to navigate to and print the node data named
One noticeable thing about the above snippet is that it is all you need to write: no imports, no need to catch exceptions, etc. Compare it to the Java code that achieves the same result.
And, most importantly, with Groovy you do not need to deploy your class and restart the server. As an additional bonus, when using the Groovy Unix-like shell which comes with the module, when you navigate a repository, by calling the
print() method on a node its children and properties are shown in the output, giving you an overview of the data structure. The screenshot below illustrates this.
print() method differs from previous versions where the data structure was displayed automatically on pressing the Enter key. However, in many cases that caused the output to be unnecessarily verbose. What is printed now by default is simply the node path.
Being able to navigate a repository data like this can come in handy, for instance, when writing and testing your own scripts or trying things out. Or when you need to use the because the Magnolia UI, for whatever reason, is not available.
node here is basically an instance of a JCR Node coated in a special "groovysh" wrapper, you to call any of the Node interface methods and take advantage of the Groovy goodies at the same time.
If you want to print out all node properties but jcr ones, you can do:
Autocompletion in the console
- Start writing a variable name and press Tab to autocomplete available variables in script context.
- Press Tab Tab to discover available variables in script context.
- Type . (dot) after a context variable and press Tab to autocomplete method names.
- Type . (dot) after a context variable and press Tab Tab to discover method names.
ctx context object is always available. In Groovy it represents
MgnlGroovyConsoleContext, a special instance of Magnolia's
Multiline code in the console
To enter multiline code in the Groovy console, press Shift + Enter at the end of each line. This enters the multiline mode. Once you've entered a block of text, press Enter at the end of the command to run it. This is useful when writing Groovy statements more complex than a simple one-liner.
Create and update properties
It is also possible to assign values to properties or create new ones.
This will assign the values on the right hand side to the properties on left hand side. Should those not exist, they will be automatically created. Moreover, the correct type will be detected based on the value assigned (
All the above assignments will be in-memory only unless explicitly persisted via a call to
save() on the current JCR session.
Use Groovy classes instead of Java classes
This feature allows you to virtually replace every Magnolia Java class with a Groovy one. Although not a major issue for most tasks, due to its dynamic nature Groovy is slower than Java. Nevertheless, replacing classes can come in handy in situations where you cannot deploy and restart the server, but need to quickly fix or add a piece of logic.
The Groovy module ships with a sample class
my.commands.GroovyMailCommand that sends an email. Here is how you could use it to create a new scheduled job on-the-fly using a Groovy command and the Scheduler module.
GroovyMailCommand is accessible in Tools > Groovy Scripts
mailhost with your SMTP server address.
Create a command configuration in the Configuration app as shown below. We added it to the Mail module in
/modules/mail/commands/default, but you can add it to your own module or another of your choice. Specify the fully qualified name of the Groovy class (matching the path in the repository where it is saved
my.commands) as if it were a plain Java class (which it actually is).
Create a scheduled job configuration referring to the command in the Configuration app >
/modules/scheduler/config/jobs. The parameters will be used at runtime by the Groovy script.
|0 0 * * * *|
|send mail every hour|
to email addresses with actual addresses.
You can use this command to replace a similar Java command at runtime. Or you can edit it and have it compiled and replaced on-the-fly (a kind of class hot deploy). This relies on the Magnolia observation mechanism. Every time the value of the
class node data changes the Groovy class will be recompiled.
Forcing Groovy class reloading
If you already set a Groovy class to replace a regular Java class in Magnolia configuration and you subsequently edit it, you'll notice that your changes aren't picked up automatically. This is a known issue but a workaround exists, i.e. manually triggering the reloading of the configuration node using your Groovy class, e.g. by modifying your template definition to force node2bean to reload it and thus reload the class itself. See also MGNLGROOVY-68 - Getting issue details... STATUS
MgnlGroovyRescueApp is a special Vaadin app that can be used to bypass the Magnolia filter chain. This is useful when you need to perform rescue operations on a corrupted Magnolia instance or when the Magnolia UI is not loading. To enable the servlet you must explicitly comment out the Magnolia filter chain in the
web.xml file and register the Groovy Rescue App.
All operations performed in the Groovy Rescue App are executed in system context, meaning no security restrictions are enforced. This might expose your data to risk of irreversible damages if you are not aware of what you are doing. In other words, use it at your own risk.
Register the Groovy Rescue App
- Stop Magnolia
/<CATALINA_HOME>/webapps/<contextPath>/WEB-INF/web.xmlin a text editor.
- Comment out the
- Add the following lines to web.xml in order to register the Groovy Rescue App:
- Save web.xml.
- Start Magnolia.
- Open a Web browser and access the Groovy Rescue App at
Make the required changes
Use Groovy commands to navigate to the data you want to change.
In the following example we delete an erroneous configuration node
- Assign the parent node content to
- Get and remove the child node
- Save the session.
Deregister Groovy Rescue App
- In web.xml, remove the servlet registration lines you added above.
- Remove comments from the filter and filter-mapping sections.
- Save web.xml.
Tomcat should notice that web.xml changed and read the changes automatically. If this does not happen, stop Magnolia, edit
web.xml, and start Magnolia again. Then try to access Magnolia.
Access scripts workspace via WebDAV
Remote client connector
The Groovy module also allows a remote Java client application to run Groovy scripts against a Magnolia server. For more information see Groovy Remote Client Connection .
The Groovy module 2.2 console has an issue that prevents one from pasting text into the console itself. Since version 2.2.2 the issue no longer affects Chrome MGNLGROOVY-104 - Getting issue details... STATUS