The Spring Cloud project has several sub projects. One of them is the Spring Cloud Config Server. With the Config Server we have a central place to manage external properties for applications with support for different environments. Configuration files in several formats like YAML or properties are added to a Git repository. The server provides an REST API to get configuration values. But there is also a good integration for client applications written with Spring Boot. And because Grails (3) depends on Spring Boot we can leverage the same integration support. Because of the Spring Boot auto configuration we only have to add a dependency to our build file and add some configuration.

Before we look at how to use a Spring Cloud Config server in our Grails application we start our own server for testing. We use a local Git repository as backend for the configuration. And we use the Spring Boot CLI to start the server. We have the following Groovy source file to enable the configuration server:

Continue reading →

Recently I wanted to use the Tuckey UrlRewriteFilter. It is described as: A Java Web Filter for any compliant web application server, which allows you to rewrite URLs before they get to your code.

I wanted to load my urlrewrite.xml as a Spring (classpath) resource, instead of loading it from the default location provided by the UrlRewriteFilter. The default behavior loads the configuration file from /WEB-INF/ulrewrite.xml. In my case I wanted to load it from the /src/main/resources folder, which is the root of my classpath.

Continue reading →

To get objects from the registry or context we specify the type of the object we want. Ratpack will find the object(s) that match the given type. If we use the get method then the last object added to the registry with the given type is returned. To get multiple objects we use the getAll method. The methods returns an Iterable with the found objects where the last added objects are returned as first elements.

In the following example specification we have a Registry with some objects, of which two are of type User. Next we use the get and getAll methods to get the objects.

Continue reading →

We can use the wiretap method of the Promise interface to listen in on results. We write an Action implementation which has the result of a Promise encapsulated in a Result object. The wiretap method can be used to do something with a Promise value without interrupting a method chain.

In the following example we tap in on Promise results:

Continue reading →

I have seen several projects where the developers had implemented caching all over the place. Caches were causing a large increase of heap usage, and users were always complaining that they were not seeing the latest data. My opinion on this is that a decision to add caching should not be taken lightly. Adding a cache means adding a lot of additional (or so-called accidental) complexity and also has a functional impact on the users. Adding a cache raises a lot of questions that need to be answered:

• What if cached data is updated, should the cached record be updated or evicted too?
• What should we do in a distributed environment, use a distributed cache? Is this distributed cache scalable?
• Do we get the performance improvements we're expecting?
• What is an acceptable delay for users to see the updated data?
• How many elements should we store in the cache?
• What eviction policy do we need when not all data fits in the cache?

Continue reading →

In a Spock specification we write our assertion in the then: or expect: blocks. If we need to write multiple assertions for an object we can group those with the with method. We specify the object we want write assertions for as argument followed by a closure with the real assertions. We don't need to use the assert keyword inside the closure, just as we don't have to use the assert keyword in an expect: or then: block.

In the following example specification we have a very simple implementation for finding an User object. We want to check that the properties username and name have the correct value.

Continue reading →

Interesting links for week 4 2016:

• The software engineer’s guide to asserting dominance in the workplace — Hacker Daily

Continue reading →

In a previous blog post we learned how to use HandlerDecorator.prepend to add common handlers via the registry in our application. The type of handlers suitable for this approach were handlers that had common functionality for the rest of the handlers. If we want to add a Chain implementation, containing handlers and maybe even path information, we cannot use the prepend method, must write our own implementation of the HandlerDecorator interface. This can be useful when we want to re-use a Chain in multiple applications. We write a module that adds the Chain implementation to the registry and we don't have to write any code in the handlers section for the Chain to work. This blog post is inspired by a conversation on the Ratpack Slack channel recently. First we create a simple handler that renders a result:

// File: src/main/groovy/com/mrhaki/ratpack/Ping.groovy
package com.mrhaki.ratpack

import ratpack.groovy.handling.GroovyChainAction

/**
 * Implementation of a {@link ratpack.handling.Chain} interface
 * by extending {@link GroovyChainAction}, so
 * we can use Groovy DSL support in the
 * {@link Ping#execute} method.
 */
class Ping extends GroovyChainAction {

    @Override
    void execute() throws Exception {
        // What we normally would write
        // in the handlers{} section
        // of Ratpack.groovy.
        path('pingpong') {
            render 'Ratpack rules!'
        }
    }
}

Continue reading →

In our Ratpack application we can have handlers that need to be invoked for every request. For example the handler needs to set a response header and will use the Context.next() method to continue with the rest of the handlers. When we have such a handler we can use the all method of a Chain instance. This happens in the handlers section of our application definition. We can also register such handlers directly in the registry. We can even use a Module to register the handler implementation. To register a handler in the registry we must use the HandlerDecorator interface. The interface has a method prepend that will encapsulate a Handler implementation and makes it available before any other handlers.

In the following sample we have a Handler implementation that checks if the RequestId object is available. If so then the value is set as a response header:

Continue reading →

A client of our Ratpack application can send a HTTP Accept header to indicate the type of response the client expects or can handle. We can restrict our application to certain types with the accepts method of the Handlers class. We can define one or more String values that denote the types that a client can use and our application responds to. If the value for the Accept header is one of the given values then the next handlers are invoked otherwise a client error 406 Not Acceptable is returned.

In the following example Ratpack application definition we use the accepts method so only values of application/json and application/xml:

Continue reading →