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 →
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 →
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.
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.
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.
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.
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.
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.
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..
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.
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.
Continue reading →
