Image of a long haired guy with a guitar

Why Groovy Scripting rocks : Use Case Alfresco

Quick turnaround is a major benefit of embedding a dynamically typed language within a Java based application. Developers no longer need to restart the whole application or the entire server for certain types of changes.

On the JVM, we have various dynamically typed languages to choose from. Ruby, Groovy, Javascript, Python and Clojure are among the candidates. They all have pros and cons so the best choice depends on the use case. This post is about Groovys pros.

Javascript in Alfresco

The Alfresco repository (and Spring Surf as well) provides an embedded Javascript interpreter (Rhino). Quite a lot can be done with a few lines of Javascript. Turnaround is far better than what you have with Java language based coding.

Still, there are things which could be improved, including:

  • Debugging Support
  • Code Reuse
  • Java Integration

Java integration cannot really be fixed due to the very nature (i.e. concepts/keywords) of Javascript. Technically, you can access the Java world:

var ctx =;
var nr1 =;
var nr2 =;

This works and gets the job done, but feels just plain wrong.

There are Javascript improvement efforts underway (links below) regarding debugging support and code reuse. I cannot really tell where they are headed now, but I hope at least the reuse changes make it into the core code soon.

The Groovy Alternative

Groovy is really outshining the competition addressing these issues. Super smooth Java integration is baked into the language. Debugging is based on JPDA/JDI – a very mature and perfectly supported technology. Even the code providing the embedded scripting was almost where I wanted it. Spring Surf sources include an extension (spring-webscripts-addon-groovy) which has a working GroovyScriptProcessor.

The only little hack tweak to get breakpoints working was to break Webscript naming convensions replacing the dot with an underscore. Hence groovy.get.groovy becomes groovy_get.groovy. Today, it is just a proof of concept but it works right as I would expect. Deploy the module, attach your IDE to the process, set a breakpoint and drive the application there:

Groovy breakpoint in Alfresco Webscript
Groovy breakpoint in Alfresco Webscript

Below is a link to the sources and a ready made module just in case you’d like to try it out. Honestly, I think Groovy deserves a little more attention in the Alfresco ecosystem. I am volunteering to push a little further.

Other Languages

In the Alfresco Repository/Spring Surf use case, I personally think you cannot beat Groovy. The only other ScriptProcessor I’m aware of is the Clojure based implementation. No doubt – the OOP <-> FP language border is rough, but Clojure is a beautiful language well worth it compared to … ;) Clojures REPL based development model makes it very appealing to me. I only had a quick glimpse at lambda-alf so far, but I will definitely have another closer look soon. I would pick Clojure next because I enjoy the language – your mileage may vary.

PS: Just in case you look at my code and wonder what is going on in DebuggableGroovyScriptProcessorFactory:
I wanted to reuse all the repository baseJavaScriptExtensions without compile time dependencies so the same Groovy ScriptProcessor works in Surf Apps just as well. The reflection mess is just the struggle with the type system.

Update April 19, 2012:

  • Forked spring-webscripts-addon-groovy at github
  • Added Peters post to the references
Download Contentreich Alfresco Repo Sandbox Module


Andreas Steffan
Pragmatic ? Scientist and DevOps Mind @ Contentreich. Believes in Open Source, the Open Web and Linux. Freelancing in DevOps-, Cloud-, Kubernetes, JVM- and Contentland and speaks Clojure, Kotlin, Groovy, Go, Python, JavaScript, Java, Alfresco and WordPress. Built infrastructure before it was cool. ❤️ Emacs.

5 thoughts on “Why Groovy Scripting rocks : Use Case Alfresco”

  1. I know Peters post – I even commented.

    The idea here is different. Peter uses a Java backed WebScript and delegation. You cannot add arbitrary WebScripts without restarting the application. I’m adding another ScriptProcessor which can replace the standard RhinoScriptProcessor. So effectively, you just replace Javascript with Groovy – not more and not less.

  2. This post highlights the advantages of Groovy based (repository-web-)-scripts compared to traditional Javascript based ones. A Grails plugin based on the Rivet Alfresco API is a very different story.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.