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 →