Author: Marius

Finding a notebook for developers


I’ve been a Mac user for all my life, but with Apple’s latest MacBook Pro, I’m pondering switching to PC/Linux. Here’s why. ▸ Read more...

Spark Summit Europe 2016

Intro ScalaDays 2016

For the second time now, the European version of the Spark Summit took place this year in Brussels after its inception last year in Amsterdam. I’ll give a short overview and summary of the talks I attended and what I gathered from speaking with attendees and companies. ▸ Read more...

Tagged with: , ,

Play’s Liaison with sbt

Have you ever wondered why you no longer play on the command line1, but execute sbt or activator? And why is Play only ever referred to in plugins.sbt and not your build.sbt’s libraryDependencies, but still, you can use its API in your code? And how does Play – run?

The sbt Plugin

The Playframework is separated into multiple modules, and with each new version, more parts of it are factored out into their own modules. The best known is simply called play – it contains the API that you as a developer interact with when developing a Play application.

The part that is running your application is actually an sbt plugin, and you can find it in the aptly named module sbt-plugin.

All plugins that your build uses must be specified in project/plugins.sbt, and are then in scope in each sub-project. To be more precise, Play is an auto-plugin2. As the name suggests, auto plugins can enable themselves automatically. Play does not use this feature however – because you want to specifically enable either the Scala or the Java plugin.

// Use Play with Scala lazy val root = (project in file(".")).enablePlugins(PlayScala) // Use Play with Java lazy val root = (project in file(".")).enablePlugins(PlayJava) ▸ Read more...

Playframework 2.4 Dependency Injection (DI)


The Playframework 2.4 has been released after one year of development with the biggest new feature being Dependency Injection (DI). But injecting dependencies, what’s the point? And why does Play require it?

Obviously you were already able to use DI in your Play applications, except for the Play API itself. In previous versions of Play, there is the central Global object which holds global mutable state. Another such object is the currently running Application. Both would cause issues in testing and in development mode when you did not organize and isolate code carefully. This leaked into the application lifecycle and the plugin system, for example you have to define a plugin priority and make sure that external components are instantiated lazily and closed after an app restart (in development mode).

Dependency Injection in Play 2.4 essentially tries1 to get rid of global state and simplifies writing isolated, resuable, and testable code by instantiating components on each reload and by providing stop hooks.

Runtime DI

The runtime DI mechanism defined by Java Specification Request 330, with its reference implementation Guice, has been selected as the default DI framework. This makes it rather straightforward to start writing new Play applications without worrying too much about DI, as components are injected automatically by using the @Inject annotation. The official documentation on runtime DI is pretty complete so I will not go into detail about it.

Compile-Time DI

Guice as a standard mechanism makes sense for a framework that offers a first-class Java API.
As a Scala developer however, you might not be too keen on relying on reflection and runtime instantiation. Luckily, Play also provides a compile-time DI mechanism.

In its simplest form, compile-time DI, or any DI for that matter, is just constructor parameter DI. All of your dependencies are declared as constructor parameters in your classes, be it controllers, actors, or any other class. The Application Loader, which replaces the Global object, prepares all dependencies and instantiates your classes by passing their dependencies into their constructor. The link from controllers to route handling is made by creating a (generated) router that maps routes to instantiated controllers – again, via its constructor.

This requires enabling injected routes in your build.sbt:

routesGenerator := InjectedRoutesGenerator

An Application Loader’s main job is to is provide the current Application.

To do this, you will assemble all of the classes required by your app. All parts of Play, now called components, support compile-time DI by providing a trait that ends with Components and builds on three basic dependencies: ApplicationLifecycle, Configuration, Environment2.

ApplicationLifecycle allows your component to register a stop hook. Configuration is the TypesafeConfig that you would previously get from a running application. Environment is a collection of methods that revolve around your running Play app, such as the classloader, dev/test/production mode, and obtaining resources.

The base component trait BuiltInComponentsFromContext extracts environment and configuration from the Application Loader’s context, and instantiates applicationLifecycle.

Let’s say we have a small app with one Application controller that needs to make a webservice call. Now instead of importing WS and the current application, we mix in a trait at the application loader level and pass a concrete WS instance to the controller.

import play.api.{ApplicationLoader, BuiltInComponentsFromContext} import import play.api.routing.Router import router.Routes // Routes are generated from routes file class AppLoader extends ApplicationLoader { override def load(context: Context): Application = new AppComponents(context).application } class AppComponents(context: Context) extends BuiltInComponentsFromContext(context) with NingWSComponents { // NingWSComponents has a lazy val wsClient lazy val applicationController = new controllers.Application(wsClient) lazy val assets = new controllers.Assets(httpErrorHandler) override def router: Router = new Routes(httpErrorHandler, applicationController) } ▸ Read more...

Play Angular Require Seed Updates

This is just a short post illustrating the latest updates in my Play-Angular-RequireJS Seed.

Play 2.4

The biggest obvious change is the update to the latest version of the Playframework, 2.4. Play 2.4 offers several ways of using Dependency Injection. In my opinion, a Scala project should aim to use compile-time DI, so the seed uses exactly that. It’s simple to use, type-safe, and eliminates a lot of global state. If you prefer using Guice or any other runtime DI mechanism, it shouldn’t be too hard to change that. ▸ Read more...