In a previous post we saw how we can use Spring Boot in a Ratpack application. But the integration can also be the other way around: using Ratpack in a Spring Boot application. This way we can use Ratpack’s power to handle requests sent to our Spring Boot application and still use all Spring Boot features in our application. The easiest way to add Ratpack to a Spring Boot application is adding a Ratpack dependency and use the
@EnableRatpack annotation. With this annotation a
RatpackServer instance is created and started along with configuration options.
When we start a Spring Boot application and pass arguments to the application, Spring Boot will capture those arguments and creates a Spring bean of type
ApplicationArguments and puts it in the application context. We can use this Spring bean to access the arguments passed to the application. We could for example auto wire the bean in another bean and use the provided argument values. The
ApplicationArguments interface has methods to get arguments values that are options and plain argument values. An option argument is prefixed with
--, for example
--format=xml is a valid option argument. If the argument value is not prefixed with
-- it is a plain argument.
When we write a Spring Boot application a lot of things are done for us. For example when an exception in the application occurs when we start our application, Spring Boot will exit the application with exit code
1. If everything goes well and the we stop the application the exit code is
0. When we use the
run method of
SpringApplication and an exception is not handled by our code, Spring Boot will catch it and will check if the exception implements the
ExitCodeGenerator interface. The
ExitCodeGenerator interface has one method
getExitCode() which must return a exit code value. This value is used as input argument for the method
System.exit() that is invoke by Spring Boot to stop the application.
Testing a Ratpack application is not difficult. Ratpack has excellent support for writing unit and integration tests. When we create the fixture
MainClassApplicationUnderTest we can override the method
addImpositions to add mock objects to the application. We can add them using the
ImpositionsSpec object. When the application starts with the test fixture the provided mock objects are used instead of the original objects. For a Groovy based Ratpack application we can do the same thing when we create the fixture
We have several options to define a Ratpack application. We can use a Java syntax to set up the bindings and handlers. Or we can use the very nice Groovy DSL. It turns out we can use both together as well. For example we can define the handlers with the Groovy DSL and the rest of the application definition is written in Java. To combine both we start with the Java configuration and use the
handlers method of the
Groovy.Script class to inject the files with the Groovy DSL.
One of the very nice features of Ratpack is the Groovy DSL to define our application. We get a nice DSL to set up the registry, to define handlers and more. Because of clever use of the
@DelegateTo annotation we get good code completion in our IDE. We can also add static compilation of our Groovy DSL when we start our Ratpack application. With static compilation the script is type checked at compile time so we get earlier feedback on possible errors in the script. To configure static compilation we must invoke the
app method of the
Groovy.Script class with the argument
Ratpack uses renderers to render output. We can create our own renderer by implementing the
Renderer interface. The renderer class needs to implement a
render method that has the object we want to render as argument. Alternatively we can add the logic to render a object to the class definition of that object. So instead of having a separate renderer class for a class, we add the render logic to the class itself. To achieve this we must implement the
Renderable interface for our class. Ratpack provides a
RenderableRenderer in the registry that knows how to render classes that implement the
We can open a Gradle project in IntelliJ IDEA and get support for Gradle inside IntelliJ. Sometimes we need to refresh the project in IntelliJ IDEA, for example when we add a new dependency or plugin in our Gradle build file. We need to refresh the Gradle project so IntelliJ IDEA can work with the changes. The Gradle tool window has an icon to Refresh all Gradle projects. But this means a mouse action and we want to have a shortcut key so we can leave our hands on the keyboard.
The action Refresh all Gradle projects is actually the action Refresh all external projects. We can add keyboard shortcut key via Preferences | Keymap. We use the search box to search for
Refresh all external projects.
We can right click on the found action and select Add Keyboard Shortcut to define a new shortcut key:
Now we simply use the shortcut to refresh our Gradle project when we have made a change in the Gradle build file that IntelliJ IDEA should know about.
Besides have the action in the Gradle tool window we can also add it to the main toolbar. We right click on the main toolbar and select the option Customize Menus and Toolbars…. We can add the action Refresh all external projects here to the toolbar:
Written with Gradle 3.4.1 and IntelliJ IDEA 2016.3.4.
Original blog post
Ratpack has parsers to parse a request with a JSON body or a HTML form. We simply use the
parse method of
Context and Ratpack will check if there is a compliant parser in the registry. If there is a parser for that type available then Ratpack will parse the request and return a
Promise with the value. To write a new parser we need to implement the
Parser interface. The easiest way to implement this interface is by writing a class that extends
ParserSupport. Using the
ParserSupport class we can also work with an options object that a user can pass on to the
parse method of
Context. If we don’t need options we can also extend the
Ratpack uses renderers to render objects with the
render method of the
Context class. Ratpack has several renderers that are available automatically. One of those renderers is the
OptionalRenderer. When we want to render an
Optional object this renderer is selected by Ratpack. If the
Optional instance has a value the value is passed to the
render method. If the value is not present a 404 client error is returned.