Coding

Handling YAML format in your REST with Spring Boot

Posted on by  
Willem Cheizoo

In general a REST service serves JSON document formats. In Spring Boot it is even the standard without having to configure anything. Over HTTP we have the ability to send a Content-Type as header to instruct the server to return a certain document format (Mime type). Besides handling JSON, XML is another common document format. But what if we want to serve or read a YAML document format? This tutorial provides the required steps to be able to handle objects in YAML format. To be able to send a YAML Content-Type with the header, and to be able to serialize and deserialize with the existing ObjectMappers of Jackson. This tutorial will use Spring Boot, Jackson and a YAML dataformat extension library for Jackson.

First we need to add the YAML Jackson extension to our Gradle build file.

Continue reading →

Gradle Goodness: Adding Task With Rule Based Model Configuration

Posted on by  
Hubert Klein Ikkink

Gradle has an incubating feature Rule based model configuration. This is a new way to configure Gradle projects where Gradle has more control of the configuration and the dependencies between configuration objects. This allows Gradle to resolve configuration values before they are used, because Gradle knows there is a dependency. With this new model we don't need any lazy evaluation "tricks" we had to use. For example there was an internal convention mapping mechanism for tasks to assign values to a task configuration after the task was already created. Also the project.afterEvalute is a mechanism to have late binding for task properties. With the new rule based model Gradle can do without these options, we can rely on Gradle resolving all dependent configuration values when we create a task.

In Gradle we already know about the "project space" where the Project object is the root of the object graph. For example repositories are part of the project space. Gradle can get some useful information from the project space, but it is mostly a graph of objects that Gradle only partially can reason about. Then we have the "model space". This is part of a project and we can use it in our build script with the model configuration block. The model space is separate from the project space and contains objects that are managed by Gradle. Gradle knows dependencies between the objects and how to create and change them. This helps Gradle to optimise build logic. To help Gradle we must define rules to work with objects in the model space. Each rule is like a recipe for Gradle on how to work with the model. Gradle can build a graph of models and know about dependencies between models. This way Gradle guarantees that model objects are completely configured before being used. For example if a rule needs a VersionFile model configuration object then Gradle makes sure that the VersionFile is created and all properties are set. So we don't need any lazy or late binding anymore, because the properties will be set (Gradle makes sure) when we want to use them. The rules are defined a class that extends RuleSource. Such a class is stateless and only contains methods to work with the model objects. Gradle has some specific annotations that can be used on methods to indicate what a method should do.

Continue reading →

Gradle Goodness: Custom Plugin Repositories With Plugins DSL

Posted on by  
Hubert Klein Ikkink

To apply a plugin in our Gradle build script we can use the plugins DSL. The plugins DSL is very concise and allows Gradle to be more efficient and more in control when loading the plugin. Normally the plugin we define is fetched from the Gradle plugin portal. If we have our own repository, for example on the intranet of our company, we have to define that extra repository with a pluginRepositories configuration block in the settings.gradle file of our project.

In the following sample we have a plugin mrhaki.gradle.version-file that is stored in the company intranet repository with the URL http://intranet/artifactory/libs-release/.

Continue reading →

Ratpacked: Creating Pairs From Promises

Posted on by  
Hubert Klein Ikkink

The Pair class in Ratpack is an easy way to create a growing data structure, passed on via Promise methods. A Pair object has a left and right part containing data. These parts can even be other Pair objects. Since Ratpack 1.4.0 the Promise class has methods to set the right or left part of a Pair: left, flatLeft, right and flatRight. The result of these methods is a Promise<Pair> object. The input can be Promise type or a Function that can use a previous Promise.

In the following example specification we use the different new methods to create a Pair. We also create a simple Ratpack server with a asynchronous HTTP client implementation to simulate remote calls returning a Promise:

Continue reading →

Groovy Goodness: Identity Closure

Posted on by  
Hubert Klein Ikkink

In functional programming we have the concept of an identity function. An identity function returns the same result as the input of the function. Groovy has a lot of functional paradigms including a identity function. Of course in Groovy's case it is an identity closure. It is defined as a constant in the Closure class: Closure.IDENTITY. If we use this closure we get the same result as the argument we provide.

In the following example we first create our own identity closure. Next we use the built-in Closure.IDENTITY closure:

Continue reading →

Exploring the Vert.x MQTT server project

Posted on by  
Rob Brinkman

In the last few years we used Vert.x to prototype and develop several IoT related projects. Most of the projects use MQTT for lightweight messaging between the connected devices (or things ;)) and the applications. The messaging is handled by an external broker liker Mosquitto. Instead of using an external broker it’s now possible to connect MQTT enabled devices directly to Vert.x using the Vert.x MQTT server project. Although the project is still in Tech Preview we’ll show you how use it to create a MQTT server within Vert.x. At first we add the snapshot repository to our build.gradle file.

repositories {
    jcenter()
    maven {
        url "https://oss.sonatype.org/content/groups/staging/"
    }
}

Continue reading →

Groovy Goodness: Interrupted Sleeping

Posted on by  
Hubert Klein Ikkink

Groovy adds a lot of useful methods to the Java JDK classes. One of them is the sleep method that is added to all objects. With the sleep method we can add a pause to our code. The sleep method accepts a sleep time in milli seconds. The implementation of the method will always wait for he given amount of milli seconds even if interrupted. But we can add a closure as extra argument, which is invoked when the sleep method is interrupted. We should return true for the closure to really interrupt, otherwise we use false.

In the following example we use the sleep method to pause the bedtime method of the User class. We run the bedtime method in a thread and after 2000 milli seconds we intercept the thread. The sleep method still wait for 5 seconds, before ending:

Continue reading →

Grails Goodness: Skip Bootstrap Code

Posted on by  
Hubert Klein Ikkink

Grails normally will run any *Bootstrap classes at startup. A Bootstrap class has a init and destroy closure. The init closure is invoked during startup and destroy when the application stops. The class name must end with Bootstrap and be placed in the grails-app/init folder. Since Grails 3.2 we can skip the execution of Bootstrap classes by setting the Java system property grails.bootstrap.skip with the value true.

In the following example Bootstrap class we simply add a println to see the effect of using the system property grails.bootstrap.skip:

Continue reading →

Groovy Goodness: Direct Field Access In (Super) Classes

Posted on by  
Hubert Klein Ikkink

When we use the property syntax of Groovy to get the value for a property, Groovy will actually try to invoke a get method for that property if it is available. So for example if we have the statement user.name actually user.getName() is invoked. If we want to reference a property field directly, so bypassing the get method, we must place an @ in front of the property field name. In the previous example we would write user.@name to get the field value directly. The same rules apply for setting a value for a property with the Groovy syntax. If we write user.name = 'mrhaki' then actually user.setName('mrhaki') is invoked. We can use the @ prefix also to set a value without invoking the set method for that property. So in our example it would be user.@name = 'mrhaki' and the setName method is not used.

In the following example we have a class Person with a name property. We add a getName method which formats the name field and returns the value. In a subclass User we access the name property from the super class using the Groovy property syntax and with the @ prefix:

Continue reading →

Devoxx4Kids: Technologie is cool

Posted on by  
Willem Cheizoo

Het is zaterdagochtend: terwijl de meeste developers uitslapen en genieten van hun vrije dag zijn een aantal JDriven collega’s al vroeg in de veren. Op naar Arnhem om kinderen in de leeftijd van 10 tot 14 jaar kennis te laten maken met programmeren. Een groep van 45 kinderen volgen drie verschillende lessen:

  1. programmeren in Scratch,

  2. python programmeren met Minecraft,

  3. zelf je mBot besturen.

Continue reading →

shadow-left