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 (_).
In the next example application we create a custom view for the Book domain class that is annotated with the @Resource annotation:
Continue reading →
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.
In the following example we have a simple Book resource.
We define it as a domain class, but tell Grails the persistence should not be handled by GORM:
Continue reading →
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.
Continue reading →
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.
In the following example we try to use an object as the first argument of the debug method in a controller class:
Continue reading →
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. To enable the view we must click on the view selector in the project view:
Continue reading →
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 →
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.
Let's create a simple controller that reads the configuration property app.message:
Continue reading →
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.
First of all we create a new class that implements the org.springframework.boot.Banner interface.
We implement the single method printBanner and logic to display a banner, including colors:
Continue reading →
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.
To create a fully executable jar file for our Grails application we must add the following lines to our build.gradle file:
Continue reading →
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..
Let's add the Grails environment the application runs in to the /info endpoint.
We create the file grails-app/conf/application.groovy.
To get the value we must have a piece of code that is executed so using the application.groovy makes this possible instead of a static configuration file like application.yml:
Continue reading →
We know Grails 3 is based on Spring Boot.
This means we can use Spring Boot features in our Grails application.
For example a default Grails application has a dependency on Spring Boot Actuator, which means we have a /info endpoint when we start the application.
We add the Git commit id and branch to the /info endpoint so we can see which Git commit was used to create the running application.
First we must add the Gradle Git properties plugin to our build.gradle file.
This plugin create a git.properties file that is picked up by Spring Boot Actuator so it can be shown to the user:
Continue reading →
When we write software it is good practice to also write tests.
Either before writing actual code or after, we still need to write tests.
In Grails we can use the test-app command to execute our tests.
If we specify the extra option -continuous Grails will monitor the file system for changes in class files and automatically compiles the code and executes the tests again.
This way we only have to start this command once and start writing our code with tests.
If we save our files, our code gets compiled and tested automatically. We can see the output in the generated HTML report or on the console.
Suppose we have our Grails interactive shell open and we type the following command:
Continue reading →
