Gradle Goodness: Changing Name of Default Build File

Gradle uses the name build.gradle as the default name for a build file. If we write our build code in a file build.gradle then we don’t have to specify the build filename when we run tasks. We can create build files with a different name other than build.gradle. For example we can define our build logic in a file sample.gradle. To run the tasks from this build file we can use the command line option -b or --build-file followed by the file name. But we can also change the project settings and set a new default build file name for our project. With the changed project settings we do not have to use the command line options -b or --build-file.

Continue reading

Grails REST: Generate RestfulController

Since version 2.3 Grails has excellent support for creating REST APIs. This new support comes with some new console commands. Besides the well known generate-controller command, Grails now comes with a new command which let you generate restful controllers for a given domain class.

In the following example, we will create a restful controller using the new generate-restful-controller command.

First we create a domain object

Second we will generate the REST controller using the new command:

This command will generate a restful controller with the name MovieController with a default REST implementation. Notable is that this generated controller does not extend RestfulController<T> but gives you a full implementation of the REST functionality inside the actions.

Below you can see for example the default implementation of the index method of the generated restful controller.

Furthermore this command will generate the REST responseType settings so both JSON and XML formats are supported.

Code written in Grails 2.4.1


Groovy Goodness: Closure as a Class

When we write Groovy code there is a big chance we also write some closures. If we are working with collections for example and use the each, collect or find methods we use closures as arguments for these methods. We can assign closures to variables and use the variable name to reference to closure. But we can also create a subclass of the Closure class to implement a closure. Then we use an instance of the new closure class wherever a closure can be used.

Continue reading

Spocklight: Indicate Class Under Test with Subject Annotation

If we write a specification for a specific class we can indicate that class with the @Subject annotation. This annotation is only for informational purposes, but can help in making sure we understand which class we are writing the specifications for. The annotation can either be used at class level or field level. If we use the annotation at class level we must specify the class or classes under test as argument for the annotation. If we apply the annotation to a field, the type of the field is used as the class under test. The field can be part of the class definition, but we can also apply the @Subject annotation to fields inside a feature method.

Continue reading

Stateless Spring Security Part 2: Stateless Authentication

This second part of the Stateless Spring Security series is about exploring means of authentication in a stateless way. If you missed the first part about CSRF you can find it here.

So when talking about Authentication, its all about having the client identify itself to the server in a verifiable manner. Typically this start with the server providing the client with a challenge, like a request to fill in a username / password. Today I want to focus on what happens after passing such initial (manual) challenge and how to deal with automatic re-authentication of futher HTTP requests.

Common approaches

Session Cookie based

The most common approach we probably all know is to use a server generated secret token (Session key) in the form of a JSESSIONID cookie. Initial setup for this is near nothing these days perhaps making you forget you have a choice to make here in the first place. Even without further using this “Session key” to store any other state “in the session”, the key itself is in fact state as well.  I.e. without a shared and persistent storage of these keys, no successful authentication will survive a server reboot or requests being load balanced to another server.

Continue reading

Stateless Spring Security Part 1: Stateless CSRF protection

Today with a RESTful architecture becoming more and more standard it might be worthwhile to spend some time rethinking your current security approaches. Within this small series of blog posts we’ll explore a few relatively new ways of solving web related security issues in a Stateless way. This first entry is about protecting your website against Cross-Site Request Forgery (CSRF).

Recap: What is Cross-Site Request Forgery?

CSRF attacks are based on lingering authentication cookies. After being logged in or otherwise identified as a unique visitor on a site, that site is likely to leave a cookie within the browser. Without explicitly logging out or otherwise removing this cookie, it is likely to remain valid for some time.

Another site can abuse this by having the browser make (Cross-Site) requests to the site under attack. For example including some Javascript to make a POST to “” will have the browser make that request, attaching any (authentication) cookies still active for that domain to the request!

Continue reading

Package-only dependencies in Maven

Sometimes you have a Maven project that needs dependencies for running tests that you do not want ending up in the final packaged WAR. We all know the test directive in the POM that accomplishes this. You might also have dependencies that are only required at runtime and need to be in the WAR but not on the compile classpath. Normally you would use the runtime directive in the POM.

Consider a situation where we have a dependency that we want to be available at runtime (in the WAR), but not on the classpath during the execution of our tests. A nice example of this is logging implementations: we want to use the slf4j-simple implementation for running unit tests, but we want logback-classic to be packaged in the WAR.

To accomplish this, you can use the maven-dependency-plugin as illustrated in the following POM snippet:

This way you have a single logging implementation on the classpath when running tests (slf4j-simple) and a single logging implementation for runtime in the final packaged WAR (logback).

Example source code

Javascript oneliners: functions are attributes too

Just a small reminder. Javascript allows you to call methods based on their name. So if a DOM element has a addClass and removeClass which both take the same argument we could write:

but we could also write

Sometimes this means you can use this technique to write powerful one liners.