Posts Tagged ‘groovy’

Using Groovy on the AWS Lambda Java8 Runtime

Posted in Code on September 11th, 2015 by ataylor284 – Comments Off on Using Groovy on the AWS Lambda Java8 Runtime

AWS Lambda is a service for running code in the cloud that manages its resources automatically. Since it provides a full Java 8 runtime, it is possible to use groovy to write your Lambda services.

When you deploy a Lambda service, you need to bundle up all your resources into a single jar file. To run groovy, you simply need to include the groovy runtime in your jar.

Gradle makes this easy. First declare groovy as a compile dependency:

dependencies {
    compile 'org.codehaus.groovy:groovy-all:2.4.4'

Next, update the jar target to include all the runtime dependencies in the jar:

jar {
    dependsOn configurations.runtime
    from {
        configurations.runtime.collect {
            it.isDirectory() ? it : zipTree(it)

This bundles all the “compile” and “runtime” dependencies into one big “fat jar”.

For a full working example, check out groovy-aws-lambda on github.

Setting Headers on URL Requests with Groovy

Posted in Code on February 6th, 2014 by ataylor284 – 2 Comments

The Java URL class can be used to send quick and dirty HTTP requests. In Groovy, it’s especially convenient to quickly get content from the web. This one-liner will fetch the page’s contents:

def webpage = "".toURL().text

Although it’s not well documented, Groovy also provides a convenient way to set headers on the request:

def json = "".toURL().
    getText(requestProperties: [Accept: 'application/json'])

See also: Url.getText(Map parameters)

Logging HttpBuilder traffic

Posted in Code on October 18th, 2013 by ataylor284 – Comments Off on Logging HttpBuilder traffic

Groovy and HttpBuilder are a nice way to write quick scripts to exercise web services. It’s especially useful when it’s just a bit too complex for something like curl. Unfortunately, there’s no quick way to trace all the I/O as with curl’s –trace, but turning on logging isn’t too difficult.

HttpBuilder uses HttpClient, which does some logging with Apache’s commons-logging. Without any additional libraries or configuration, it will fall back on Java’s java.util.logging package. Java expects it’s logging configuration in a properties file. Here’s a minimal config:


Launch groovy with the right system property, and all the output will be logged.

groovy \

Creating a Groovy ConfigObject from a Closure

Posted in Code on January 22nd, 2013 by ataylor284 – 5 Comments

The Groovy ConfigObject and ConfigSlurper are very nice for replacing properties and XML configuration files with Groovy. Surprisingly though, there’s no obvious way to get a ConfigObject directly from a closure. The interface requires either the URL or filename of a script file, or a Script object.

Fortunately, there’s an easy way wrap a closure to make it work like a Script:

class ClosureScript extends Script {
    Closure closure
    def run() {
        closure.resolveStrategy = Closure.DELEGATE_FIRST
        closure.delegate = this

This makes it trivial to include a configuration configuration directly inside a script and treat it just like an external script.

def config = {
  environments {
    development {
      host = 'localhost'
      port = 8080
def env = 'development'
def settings = new ConfigSlurper(env).
    parse(new ClosureScript(closure: config))
println "host is $, port is $settings.port"

Downloading a Server’s HTTPS Certificate with Groovy

Posted in Code on August 2nd, 2012 by ataylor284 – 1 Comment

If you ever need to access a web service with HTTPS as a client in Java or groovy, and the service uses a self-signed certificate, you might need to import the SSL certificate into your local keystore.

To import the certificate, first you need to get it from the remote web server. Here’s a convenient little groovy script that downloads the certificate as a X509Certificate.


if (args.size() != 2) {
    println "usage: getCert host port"
def (host, port) = args
def cert
def trustManager = [
    checkClientTrusted: { chain, authType ->  },
    checkServerTrusted: { chain, authType -> cert = chain[0] },
    getAcceptedIssuers: { null }
] as X509TrustManager

def context = SSLContext.getInstance("TLS")
context.init(null, [trustManager] as TrustManager[], null)
context.socketFactory.createSocket(host, port as int).with {
println "-----BEGIN CERTIFICATE-----"
println cert.encoded.encodeBase64(true)
println "-----END CERTIFICATE-----"

This program prints out the certificate in a format that can be fed to keytool like so:

# get the certificate from the remote server
groovy getCert testserver 443 > certificate.txt
# print out the certificate details in a readable format
keytool -printcert -file certificate.txt
# import the certificate into the local keystore
keytool -import -file certificate.txt -alias testserver -keystore $JAVA_HOME/jre/lib/security/cacerts

Simple Servlets in Groovy

Posted in Code on February 29th, 2012 by ataylor284 – 12 Comments

A feature I miss in groovy is a simple way to create a self-contained web server without a web container like Tomcat. Python, in particular, has a nice solution for this with its HTTPServer class. It’s not something to write a full application with, but it’s an extremely convenient tool to have available.

The best solution I’ve found is Jetty, the embedded Java web server. It has a nice simple interface and runs any Servlet right out of your script:

@Grab(group='org.mortbay.jetty', module='jetty-embedded', version='6.1.26')
import org.mortbay.jetty.Server
import org.mortbay.jetty.servlet.*

def runWithJetty(servlet, port) {
   def jetty = new Server(port)
   def context = new Context(jetty, '/', Context.SESSIONS)
   context.addServlet(new ServletHolder(servlet), '/*')

Groovy has groovlets and GroovyServlet, a nice little wrapper for writing Servlets. However, it requires you to structure your project in a specific way: each Servlet in a separate file, mapped to URI paths by file name.

By hooking up ServletCategory and ServletBinding to a closure, it’s possible to get the nice features of groovlets without the GroovyServlet limitations:

@Grab(group='org.mortbay.jetty', module='jetty-embedded', version='6.1.26')
import org.mortbay.jetty.Server
import org.mortbay.jetty.servlet.*
import groovy.servlet.*
import javax.servlet.http.*
import javax.servlet.ServletConfig

class SimpleGroovyServlet extends HttpServlet {
    def requestHandler
    def context
    void init(ServletConfig config) {
        context = config.servletContext
    void service(HttpServletRequest request, HttpServletResponse response) {
        requestHandler.binding = new ServletBinding(request, response, context)
        use (ServletCategory) {
    static void run(int port, Closure requestHandler) {
        def servlet = new SimpleGroovyServlet(requestHandler: requestHandler)
        def jetty = new Server(port)
        def context = new Context(jetty, '/', Context.SESSIONS)
        context.addServlet(new ServletHolder(servlet), '/*')

Combined with the above, a simple self-contained web server becomes as clean and concise as groovy should be: { ->
    response.contentType = 'text/plain'
    println "hello world!"
    println "my path is ${request.pathInfo}"
    println "my params are $params"

Guess the Content-type from Filename

Posted in Code on January 17th, 2012 by ataylor284 – Comments Off on Guess the Content-type from Filename

Java has a helpful little function for guessing the content-type based on the file name:


You can check out — or customize — the mappings which are stored in $JRE_HOME/lib/

So if you’re serving up a file and you’re not quite sure what content-type to use, let Java take a guess.

Groovy multimethods and the visitor pattern

Posted in Code on September 23rd, 2011 by ataylor284 – 4 Comments

Visitor is one of the classic GOF patterns. It’s a great pattern for traversing and operating on objects. It’s particularly useful when your application is centered around a big data structure, like a compiler’s abstract syntax tree, or a browser’s document object model.

Java Implementation

The usual Java implementation needs a bit of code to work around how Java chooses methods. Java resolves every method call by the runtime type of the owning object, plus the types of the parameters. But when it considers the parameters, it uses their declared classes.

Below is a common implementation of the pattern.

When visit is called directly in Java, then instances of B or C will be dispatched to the wrong visit method. So an accept method is added to every visited class. accept simply calls visit on the visitor with this as a parameter. It can’t be inherited, since it’s purpose is to call visit with the right declared type.

import java.util.*;

public class JavaVisitor implements ABCVisitor {

    public void visit(Collection<A> collection) {
        for (A a : collection) {
            //visit(a);       // outputs A A A
            a.accept(this);   // outputs A B C

    public void visit(A x) {

    public void visit(B x) {

    public void visit(C x) {

    public static void main(String[] args) {
        JavaVisitor v = new JavaVisitor();
        List<A> alist = new ArrayList<A>();
        alist.add(new A());
        alist.add(new B());
        alist.add(new C());


interface ABCVisitor {
    void visit(A x);
    void visit(B x);
    void visit(C x);

class A { 
    void accept(ABCVisitor visitor) {

class B extends A {
    void accept(ABCVisitor visitor) {

class C extends B {
    void accept(ABCVisitor visitor) {

Groovy Implementation

One of the overlooked features of groovy is multiple method dispatch, or multimethods. Groovy resolves method calls by the actual parameter types, determined at runtime.

This just happens to make visitor a lot easier to implement. The double dispatch through accept is completely unnecessary. Unlike Java, visit can just be called directly.

class GroovyVisitor implements Runnable {

    void visit(Collection collection) {
        for (a in collection) {

    void visit(A x) {

    void visit(B x) {

    void visit(C x) {

    void run() {
        visit([new A(), new B(), new C()])

class A { 

class B extends A {

class C extends B {

Now the classes being visited don’t need to follow any specific protocol. They can be any classes at all, including third party library classes not designed to be visited.

The ABCVisitor interface, which has to enumerate all the potential visited classes, is completely unnecessary. The code is clear and to the point, and completely encapsulated in the visitor class. It’s short, concise, without any unnecessary implementation details just like good groovy code should be.

mapcan in groovy

Posted in Code on February 9th, 2011 by ataylor284 – Comments Off on mapcan in groovy

Groovy has borrowed most of the good stuff from functional and higher-order languages, but one operation I miss is mapcan. mapcan comes from lisp and while it’s a bit hard to describe, it ends up being useful in a lot of situations. It’s very similar to mapcar, except instead of transforming one element to one element, it transforms one element to zero or more elements. In groovy terms, it’s like collect where collect’s closure could return a list of elements instead of just one. It a way, it’s kind of like a combination of collect and findAll on steroids.

In lisp, it looks like this:

(defvar *interface-methods*
  '((:Serializable . ())
    (:Comparable . (:compareTo))
    (:Iterator . (:hasNext :next :remove))))

(print (mapcan #'cdr *interface-methods*))
;; evaluates to '(:compareTo :hasNext :next :remove)

A first cut in groovy might look like:

Collection.metaClass.mapcan = { cl -> 

The problem with that implementation is that flatten is recursive and will flatten nested lists too. He’s another approach with inject:

Collection.metaClass.mapcan = { cl ->
    delegate.inject([]) {collection, it -> collection + cl(it)}

The mapcan name doesn’t really fit with groovy, so I renamed it collectn instead. Here are some examples of its use:

Collection.metaClass.collectn = { cl ->
    delegate.inject([]) {collection, it -> collection + cl(it)}

def s = ["", "zero", "or more", "words per string"]
assert s.collectn { it.tokenize() }.sort() ==
    ["zero", "or", "more", "words", "per", "string"].sort()

Map.metaClass.collectn = { cl ->
    delegate.inject([]) {collection, it -> collection + cl(it)}

def interfaceMethods = [
    Serializable: [],
    Comparable: ['compareTo'],
    Iterator: ['hasNext', 'next', 'remove']
assert interfaceMethods.collectn { it.value }.sort() == 
    ['compareTo', 'hasNext', 'next', 'remove'].sort()