Archive: 2016

Ratpacked: Execute Code On Start and Stop Application Lifecycle Events

Posted on by  
Hubert Klein Ikkink

Ratpack has the ratpack.server.Service interface with the methods onStart and onStop. If we write an implementation class for the Service interface and register it with the Ratpack registry, then Ratpack will invoke the onStart method when the application starts and the onStop method when the application stops. The methods take an event object as argument and we can use the event object to access the registry if we need to. Writing an implementation for the Service interface can be useful for example to bootstrap the application with initial data or do other things.

In the following example implementation we log when the application starts and stops. In the onStart method we also display a Ratpack banner on the console.

Continue reading →

Ratpacked: Respond To Custom MIME Types

Posted on by  
Hubert Klein Ikkink

In Ratpack we can use the byContent method on the Context object to send different responses based on the requested MIME type from the client. There is already support for application/json, application/xml, text/plain and text/html MIME types with corresponding methods of the ByContentSpec object that is passed as argument to the byContent method. We can match on a custom MIME type with the method type and specify the MIME type. If the type matches we can create a response.

In the following example application we have a custom renderer for a User object:

Continue reading →

Ratpacked: Register Renderer For A List Of Objects

Posted on by  
Hubert Klein Ikkink

When we use the render method in our Ratpack application then Ratpack will use the type of the object we want to render to find an appropriate renderer. Some renderers are built-in, like a Promise or CharSequence renderer. We can write our own renderers by implementing the ratpack.render.Renderer interface. Next we must register our renderer in the Ratpack registry.

In our example application we have a very simple User class:

Continue reading →

Ratpacked: Add Response Time To Response Header

Posted on by  
Hubert Klein Ikkink

Ratpack has the class ratpack.handling.ReponseTimer which adds a header with the name X-Response-Time to the response. The value is the time spent in code from when the request comes in and the response is sent out. ResponseTimer is a handler we can add in our application. Alternatively we can use the static method decorator to get a handler decorator. With a handler decorator we can use the registry to add handler logic in our application.

First we use the ResponseTimer as a handler:

Continue reading →

Throttling in Akka and Spray

Posted on by  
Tammo Sminia

When you want to limit the amount of messages an actor gets, you can use the throttler in akka-contrib. This will let you limit the max transactions per second(tps). It will queue up the surplus. Here I'll describe another way. I'll reject all the surplus messages. This has the advantage that the requester knows it's sending too much and can act on that. Both methods have their advantages. And both have limits, since they still require resources to queue or reject the messages. In Akka we can create an Actor that sends messages through to the target actor, or rejects them when it exceeds the specified tps.

object ThrottleActor {
  object OneSecondLater
  object Accepted
  object ExceededMaxTps
}
import ThrottleActor._

class ThrottleActor (target: ActorRef, maxTps: Int) extends Actor with ActorLogging {
  implicit val executionContext: ExecutionContext = context.dispatcher
  context.system.scheduler.schedule(1.second, 1.second, self, OneSecondLater)

  var messagesThisSecond: Int = 0

  def receive = {
    case OneSecondLater =>
      log.info(s"OneSecondLater ${DateTime.now} $messagesThisSecond requests.")
      messagesThisSecond = 0
    case message if messagesThisSecond >= maxTps =>
      sender ! ExceededMaxTps
      messagesThisSecond += 1
      log.info(s"ExceededMaxTps ${DateTime.now} $messagesThisSecond requests.")
    case message =>
      sender ! Accepted
      target ! message
      messagesThisSecond += 1
  }
}

Continue reading →

Ratpacked: Extending GroovyChain DSL

Posted on by  
Hubert Klein Ikkink

Russel Hart has a nice example on how to extend the Ratpack Groovy DSL in the hands on ratpack project on Github. We can use the Groovy extension module feature to add new methods to arbitrary classes. If we use this to add new methods to the GroovyChain class we can use those methods in the DSL of our Groovy Ratpack application.

A Groovy extension module is just a class with a definition of the new methods we want to add to a class. The first argument of the method is the class the method is added to and the remaining arguments can be used by the implementation. We also need to create a supporting file org.codehaus.groovy.runtime.ExtensionModule with some information about our extension class. This supporting file needs to be in the classpath in the directory META-INF/services.

Continue reading →

Ratpacked: Using Names With Regular Expression Tokens

Posted on by  
Hubert Klein Ikkink

In a previous post we have seen how to use regular expressions for path tokens. We can also name the path token for which the regular expression applies. This makes it easier to get the value in our handler code: we can just refer to the name. Also we can add a question mark to the name to make the token optional.

In the following example we use the name conferenceName for the path token with the regular expression Gr\w+:

Continue reading →

Ratpacked: Special Routing Of Promise Values Using Predicates

Posted on by  
Hubert Klein Ikkink

One of the strengths of Ratpack is the asynchronous execution model. An important class is the Promise class. An instance of the class will represent a value that is available later. We can invoke several operations that need be applied to a value when a Promise is activated. Usually the activation happens when we subscribe to a Promise using the then method. We can use the route method for a Promise to have a different action when a certain predicate is true. The action will stop the flow of operations, so methods that are executed after the route method are not executed anymore if the predicate is true. If the predicate is false then those methods are invoked.

The Promise class has a method onNull as a shorthand for the route method where the predicate checks if the value is null. For example we could have a service in our application that returns a Promise. If the value is null we want some special behaviour like sending a 404 status code to the client. With the following code we could achieve this:

Continue reading →

Change Font Size With Mouse In IntelliJ IDEA

Posted on by  
Hubert Klein Ikkink

We can change the font size in our editor using shortcut keys in IntelliJ IDEA. But we can also use our mouse wheel to do this. We must enable this option in the settings of IntelliJ IDEA. We select the Preferences and then General | Editor. Here we select the option Change font size (Zoom) with Command+Mouse Wheel:

Continue reading →

Grails Goodness: Go To Related Classes In IntelliJ IDEA

Posted on by  
Hubert Klein Ikkink

Normally in a Grails application we have classes that are related to each other, but are located in different directories. For example a controller with several views. Or a Grails service with corresponding specifications. In IntelliJ IDEA we can use Choose Target and IDEA will show classes, files and methods that are relevant for the current file we are editing. The keybinding on my Mac OSX is Ctrl+Cmd+Up, but can be different on your computer and operating system. We can also choose the menu option Navigate | Related symbol....

In the following example we are editing the file MessagesController. We select the action Choose Target, IntelliJ IDEA shows a popup menu with the views for this controller and the specification class:

Continue reading →

Grails Goodness: Change Locale With Request Parameter

Posted on by  
Hubert Klein Ikkink

Grails has internationalisation (i18n) support built-in. It is very easy to add messages for different locales that can be displayed to the user. The messages are stored in properties files in the directory grails-app/i18n. Grails checks the request Accept-Language header to set the default locale for the application. If we want to force a specific locale, for example for testing new messages we added to the i18n property files, we can specify the request parameter lang. We specify a locale value and the application runs with that value for new requests.

The following screenshot shows a scaffold controller for a Book domain class with a default locale en:

Continue reading →

shadow-left