JDriven Blog

Grails Goodness: Render Binary Output with the File Attribute

Posted on by  
Hubert Klein Ikkink

Since Grails 2 we can render binary output with the render() method and the file attribute. The file attribute can be assigned a byte[], File, InputStream or String value. Grails will try to determine the content type for files, but we can also use the contentType attribute to set the content type.

In the following controller we find an image in our application using grailsResourceLocator. Then we use the render() method and the file and contenType attributes to render the image in a browser:

Continue reading →

Grails Goodness: Accessing Resources with Resource and ResourceLocator

Posted on by  
Hubert Klein Ikkink

Grails uses Spring and we can piggyback on the Spring support for resource loading to find for examples files in the classpath of our application. We can use the Spring org.springframework.core.io.Resource or org.springframework.core.io.ResourceLoader interface to find resources in our application.

And since Grails 2.0 we can also use the org.codehaus.groovy.grails.core.io.ResourceLocator interface. In our code we can use the grailsResourceLocator service which implements the ResourceLocator interface. We must inject the grailsResourceLocator service into our code and we use the method findResourceForURI(String) to find a resource. The advantage of the grailsResourceLocator service is that it knows about a Grails application. For example resources in plugins can also be accessed.

Continue reading →

Spocklight: Using the Old Method

Posted on by  
Hubert Klein Ikkink

Spock has some great features to write specifications or tests that are short and compact. One of them is the old() method. The old() method can only be used in a then: block. With this method we get the value a statement had before the when: block is executed.

Let's see this with a simple example. In the following specification we create a StringBuilder with an initial value. In the then: block we use the same initial value for the assertion:

Continue reading →

Grails Goodness: Set Request Locale in Unit Tests

Posted on by  
Hubert Klein Ikkink

There is really no excuse to not write unit tests in Grails. The support for writing tests is excellent, also for testing code that has to deal with the locale set in a user's request. For example we could have a controller or taglib that needs to access the locale. In a unit test we can invoke the addPreferredLocale() method on the mocked request object and assign a locale. The code under test uses the custom locale we set via this method.

In the following controller we create a NumberFormat object based on the locale in the request.

Continue reading →

Grails Goodness: Using the header Method to Set Response Headers

Posted on by  
Hubert Klein Ikkink

Grails adds a couple of methods and properties to our controller classes automatically. One of the methods is the header() method. With this method we can set a response header with a name and value. The methods accepts two arguments: the first argument is the header name and the second argument is the header value.

In the following controller we invoke the header() method to set the header X-Powered-By with the Grails and Groovy version.

Continue reading →

Integrating Karma 0.8 tests in Maven with Sonar(Cube) test coverage

Posted on by  
Emil van Galen

NOTE: this blog post was written for version 0.8 of the Karma test runner. An updated blog post for the new Karma 0.10 can be found here.

For my current project we are using Maven to build our AngularJS application. Furthermore we use Sonar (recently renamed to SonarCube) to monitor our code standards / best practices and unit test coverage. In this blog post we describe how to integrate the Karma (Testacular) test runner with Maven and how to add your AngularJS (or any JavaScript) application to SonarQube.

Continue reading →

Clone Hibernate Objects

Posted on by  
Sjoerd Schunselaar

When we want to clone an object there are several ways to do this For instance we can implement Clonable, which makes it possible to duplicate an object. We also can create a new object manually by calling each setter or use a parameterised constructor. In case we want to clone a Hibernate object, there is an extra option available which is more elegant: the Hibernate3BeanReplicator. The Hibernate3BeanReplicator is provided by Beanlib (http://beanlib.sourceforge.net/) and it supports deep clones, so we can also clone related one-to-one objects easily. For example we want to clone the Student object, including all child (one-to-one) objects.

Student student = studentDao.getStudentById(1);

HibernateBeanReplicator replicator = new Hibernate3BeanReplicator();
Student studentCopy = replicator.deepCopy(student);

studentCopy.setId(null);
studentCopy.getRelatedObject().setId(null);

studentDao.save(studentCopy);

Continue reading →

Groovy Goodness: Customize Log Variable Name with Log AST Annotations

Posted on by  
Hubert Klein Ikkink

To add logging to a class with Groovy is easy. We apply one of the logging AST transformations and we get a variable in our class named log. We can invoke methods on the variable and the AST transformation will also automatically wrap those statement in a "if-logging-level-is-enabled" block. The transformation is even intelligent enough to do this only if Strings are added or a GString is used. If we want to use a different name than log we simply use the value parameter of the annotation. We assign the name we want to use and then we can use it in our code.

import groovy.util.logging.*

@Log(value = 'LOGGER')
class Event {
    String name
    Boolean started

    void start() {
        LOGGER.info "Event $name is started"
        started = true
    }
}

final Event event = new Event(name: 'gr8Conf')
event.start()

Continue reading →

Gradle Goodness: Extending DSL

Posted on by  
Hubert Klein Ikkink

Gradle already has a powerful DSL, but Gradle wouldn't be Gradle if we couldn't extend the DSL ourselves. Maybe we have our own naming conventions in our company or we have a special problem domain we want to express in a Gradle build script. We can use the ExtensionContainer, available via project.extensions, to add new concepts to our build scripts. In the Standardizing your enterprise build environment webinar by Luke Daley some examples are shown on how to extend the DSL. Also in the samples folder of the Gradle distribution are examples on how to create a custom DSL.

Let's first create a simple DSL extension. We first define a new class CommonDependencies with methods to define dependencies in a Java project. We want to use these methods with descriptive names in our build scripts. To add the class we use the create() method of the ExtensionContainer. The first argument is a name that needs to be unique within the build. The name can be used together with a configuration block in the script to invoke methods on the class we pass as the second argument. Finally we can pass constructor arguments for the class as last arguments of the create() method.

Continue reading →

shadow-left