Grails Goodness: Custom JSON and Markup Views For Default REST Resources

Posted on March 2, 2017 by mrhaki

In Grails we can use the @Resource annotation to make a domain class a REST resource. The annotation adds a controller as URL endpoint for the domain class. Values for the domain class properties are rendered with a default renderer. We can use JSON and markup views to customize the rendering of the domain class annotated with a @Resource annotation. First we must make sure we include views plugin in our build configuration. Then we must create a directory in the grails-app/views directory with the same name as our domain class name. Inside the directory we can add JSON and markup views with names that correspond with the controller actions. For example a file index.gson or index.gml for the index action. We can also create a template view that is automatically used for a resource instance by adding a view with the name of the domain class prefixed with an underscore (_).

Continue reading →

Grails Goodness: Using Domain Classes Without Persistence

Posted on February 24, 2017 by mrhaki

Normally when we create a domain class in Grails we rely on GORM for all the persistence logic. But we can use the static property mapWith with the value none to instruct Grails the domain class is not persisted. This can be useful for example if we want to use a RestfulController for a resource and use the default data binding support in the RestfulController. The resource must be a domain class to make it work, but we might have a custom persistence implementation that is not GORM. By using the mapWith property we can still have benefits from the RestfulController and implement our own persistence mechanism.

Continue reading →

Gradle Goodness: Passing Environment Variable Via Delegate Run Action In IntelliJ IDEA

Posted on January 5, 2017 by mrhaki

IntelliJ IDEA 2016.3 introduced the option to delegate the run action to Gradle. This means when we have a run Configuration for our Java or Groovy classes we can use the Run action and IDEA will use Gradle to run the application. Actually IntelliJ IDEA creates a new task of type JavaExec dynamically for our specific run configuration with the main property set to the class we want to run.

In the Edit Configuration dialog window we can set the command line argument and Java system properties. These are passed on to the dynamically created JavaExec task and are accessible from within the class that runs. The environment variables that can be set in the Edit Configuration dialog windows are not passed to the JavaExec task configuration. But we can do it ourselves in the build script file of our project. We look for the dynamically created task and use the environment method to add a environment variable that can be access in the Java or Groovy class that is executed.

We start our example with a simple Groovy class that can be executed using JavaExec. We simply print out the given input arguments, all Java system properties that start with sampleApp and finally all environment variables that start with SAMPLE_APP:

// File: src/main/groovy/mrhaki/gradle/SampleApp.groovy
package mrhaki.gradle

class SampleApp {

    static void main(final String[] args) {
        final app = new SampleApp()
        app.printArgs(args)
        app.printSystemProperties()
        app.printEnv()
    }

    void printArgs(final String[] args) {
        printSection 'Command line arguments', args
    }

    void printSystemProperties() {
        printSection 'System properties', System.properties.findAll(findNameStartsWith('sampleApp'))
    }

    void printEnv() {
        printSection 'environment', System.getenv().findAll(findNameStartsWith('SAMPLE_APP'))
    }
    
    private void printSection(final String title, final values) {
        println "--- $title ---"
        println values
    }

    private Closure findNameStartsWith(final String search) {
        { name, value -> name.startsWith(search) }
    }
    
}

// File: src/main/groovy/mrhaki/gradle/SampleApp.groovy

package mrhaki.gradle

class SampleApp {

static void main(final String[] args) {

final app = new SampleApp()

app.printArgs(args)

app.printSystemProperties()

app.printEnv()

}

void printArgs(final String[] args) {

printSection 'Command line arguments', args

}

void printSystemProperties() {

printSection 'System properties', System.properties.findAll(findNameStartsWith('sampleApp'))

}

void printEnv() {

printSection 'environment', System.getenv().findAll(findNameStartsWith('SAMPLE_APP'))

}

private void printSection(final String title, final values) {

println "--- $title ---"

println values

}

private Closure findNameStartsWith(final String search) {

{ name, value -> name.startsWith(search) }

}

We create a new Run/Debug Configuration for our SampleApp class:

When we click on OK to save the configuration we are ready to use the Run ‘SampleApp’ action. When we look at the output we get the following result:

10:54:29: Executing external task 'run SampleApp'...
:compileJava UP-TO-DATE
:compileGroovy 
:processResources UP-TO-DATE
:classes 
:run SampleApp
--- Command line arguments ---
[Execute via IDEA delegate to Gradle]
--- System properties ---
[sampleApp:Gradle Galore]
--- environment ---
[:]

BUILD SUCCESSFUL

Total time: 3.539 secs
10:54:33: External task execution finished 'run SampleApp'.

10:54:29: Executing external task 'run SampleApp'...

:compileJava UP-TO-DATE

:compileGroovy

:processResources UP-TO-DATE

:classes

:run SampleApp

--- Command line arguments ---

[Execute via IDEA delegate to Gradle]

--- System properties ---

[sampleApp:Gradle Galore]

--- environment ---

[:]

BUILD SUCCESSFUL

Total time: 3.539 secs

10:54:33: External task execution finished 'run SampleApp'.

Notice the Gradle tasks that are invoked and the dynamically created run SampleApp task. We see our Java system property is passed on, together with the program arguments. The environment variable is not passed on. We must add some extra configuration to the dynamically created task run Sample in our build.gradle file:

// File: build.gradle
...
setEnvVarRunConfiguration 'SampleApp', 'SAMPLE_APP', 'Gradle environment variable'

/**
 * Add environment variable to JavaExec task
 * configuration created by IntelliJ IDEA
 * from a Run/Debug configuration.
 * 
 * @param configuration Name of IntelliJ IDEA Run/Debug configuration
 * @param envName Name of environment variable
 * @param envValue Value for environment variable
 */
def setEnvVarRunConfiguration(
        final String configuration, 
        final String envName, 
        final String envValue) {

    // Find task by type JavaExec and matching 
    // task name for configuration name.
    final javaExecRunConfiguration = { task ->
        task instanceof JavaExec && task.name == "run $configuration"
    }
    
    tasks.matching(javaExecRunConfiguration).all {
        // Add environment variable to JavaExec 
        // task configuration.
        environment envName, envValue
    }
}
...

// File: build.gradle

...

setEnvVarRunConfiguration 'SampleApp', 'SAMPLE_APP', 'Gradle environment variable'

/**

* Add environment variable to JavaExec task

* configuration created by IntelliJ IDEA

* from a Run/Debug configuration.

* @param configuration Name of IntelliJ IDEA Run/Debug configuration

* @param envName Name of environment variable

* @param envValue Value for environment variable

def setEnvVarRunConfiguration(

final String configuration,

final String envName,

final String envValue) {

// Find task by type JavaExec and matching

// task name for configuration name.

final javaExecRunConfiguration = { task ->

task instanceof JavaExec && task.name == "run $configuration"

}

tasks.matching(javaExecRunConfiguration).all {

// Add environment variable to JavaExec

// task configuration.

environment envName, envValue

}

...

Now we re-run our application and we get the following output:

11:29:19: Executing external task 'run SampleApp'...
:compileJava UP-TO-DATE
:compileGroovy UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:run SampleApp
--- Command line arguments ---
[Execute via IDEA delegate to Gradle]
--- System properties ---
[sampleApp:Gradle Galore]
--- environment ---
[SAMPLE_APP:Gradle environment variable]

BUILD SUCCESSFUL

Total time: 0.599 secs
11:29:19: External task execution finished 'run SampleApp'.

11:29:19: Executing external task 'run SampleApp'...

:compileJava UP-TO-DATE

:compileGroovy UP-TO-DATE

:processResources UP-TO-DATE

:classes UP-TO-DATE

:run SampleApp

--- Command line arguments ---

[Execute via IDEA delegate to Gradle]

--- System properties ---

[sampleApp:Gradle Galore]

--- environment ---

[SAMPLE_APP:Gradle environment variable]

BUILD SUCCESSFUL

Total time: 0.599 secs

11:29:19: External task execution finished 'run SampleApp'.

Written with IntelliJ IDEA 2016.3 and Gradle 3.2.1.

Original blog post

Grails Goodness: Writing Log Messages With Grails 3.2 (Slf4J)

Posted on January 3, 2017 by mrhaki

Grails 3.2 changed the logging implementation for the log field that is automatically injected in the Grails artefacts, like controllers and services. Before Grails 3.2 the log field was from Jakarta Apache Commons Log class, but since Grails 3.2 this has become the Logger class from Slf4J API. A big difference is the fact that the methods for logging on the Logger class don’t accepts an Object as the first argument. Before there would be an implicit toString invocation on an object, but that doesn’t work anymore.

Continue reading →

Grails Goodness: Enabling Grails View In IntelliJ IDEA For Grails 3

Posted on December 12, 2016 by mrhaki

IntelliJ IDEA 2016.3 re-introduced the Grails view for Grails 3 applications. Grails 2 applications already were supported with a Grails view in IDEA. Using this view we get an overview of all the Grails artifacts like controller, services, views and more. We can easily navigate to the the class files we need. Now this view is also available for Grails 3 applications. Continue reading →

Grails Goodness: Skip Bootstrap Code

Posted on October 30, 2016 by mrhaki

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.

Continue reading →

Grails Goodness: Pass JSON Configuration Via Command Line

Posted on July 7, 2016 by mrhaki

We can use the environment variable SPRING_APPLICATION_JSON with a JSON value as configuration source for our Grails 3 application. The JSON value is parsed and merged with the configuration. Instead of the environment variable we can also use the Java system property spring.application.json.

Continue reading →

Grails Goodness: Add Banner To Grails 3.1 Application

Posted on June 28, 2016 by mrhaki

In a previous post we learned how to add a banner to a Grails 3.0 application. We used the Spring Boot support in Grails to show a banner on startup. The solution we used doesn’t work for a Grails 3.1 application. We need to implement a different solution to show a banner on startup.

Continue reading →

Grails Goodness: Creating A Fully Executable Jar

Posted on June 27, 2016 by mrhaki

With Grails 3 we can create a so-called fat jar or war file. To run our application we only have to use java -jar followed by our archive file name and the application starts. Another option is to create a fully executable jar or war file, which adds a shell script in front of the jar or war file so we can immediately run the jar or war file. We don’t have to use java -jar anymore to run our Grails application. The fully executable JAR file can only run on Unix-like systems and it is ready to be used as service using init.d or systemd.

Continue reading →

Grails Goodness: Adding Custom Info To Info Endpoint

Posted on June 24, 2016 by mrhaki

In a previous post we learned how to add Git commit information to the /info endpoint in our Grails application. We can add our own custom information to this endpoint by defining application properties that start with info..

Continue reading →