You are viewing the documentation for the 2.7.0-M4 development release. The latest stable release series is 3.0.x.

§Compile Time Dependency Injection

Out of the box, Play provides a mechanism for runtime dependency injection - that is, dependency injection where dependencies aren’t wired until runtime. This approach has both advantages and disadvantages, the main advantages being around minimisation of boilerplate code, the main disadvantage being that the construction of the application is not validated at compile time.

An alternative approach is to use compile time dependency injection. At its simplest, compile time DI can be achieved by manually constructing and wiring dependencies. Other more advanced techniques and tools exist, such as Dagger. All of these can be easily implemented on top of constructors and manual wiring, so Play’s support for compile time dependency injection is provided by providing public constructors and factory methods as API.

Note: If you’re new to compile-time DI or DI in general, it’s worth reading Adam Warski’s guide to DI in Scala that discusses compile-time DI in general. While this is an explanation for Scala developers, it could also give you some insights about the advantages of Compile Time Injection.

In addition to providing public constructors and factory methods, all of Play’s out of the box modules provide some interface that implement a lightweight form of the cake pattern, for convenience. These are built on top of the public constructors, and are completely optional. In some applications, they will not be appropriate to use, but in many applications, they will be a very convenient mechanism to wiring the components provided by Play. These interfaces follow a naming convention of ending the trait name with Components, so for example, the default HikariCP based implementation of the DB API provides a interface called HikariCPComponents.

Note: Of course, Java has some limitations to fully implement the cake pattern. For example, you can’t have state in interfaces.

In the examples below, we will show how to wire a Play application manually using the built-in component helper interfaces. By reading the source code of the provided component interfaces it should be trivial to adapt this to other dependency injection techniques as well.

§Application entry point

Every application that runs on the JVM needs an entry point that is loaded by reflection - even if your application starts itself, the main class is still loaded by reflection, and its main method is located and invoked using reflection.

In Play’s dev mode, the JVM and HTTP server used by Play must be kept running between restarts of your application. To implement this, Play provides an ApplicationLoader interface that you can implement. The application loader is constructed and invoked every time the application is reloaded, to load the application.

This interfaces’s load method takes as an argument the application loader Context, which contains all the components required by a Play application that outlive the application itself and cannot be constructed by the application itself. A number of these components exist specifically for the purposes of providing functionality in dev mode, for example, the source mapper allows the Play error handlers to render the source code of the place that an exception was thrown.

The simplest implementation of this can be provided by extending the Play BuiltInComponentsFromContext abstract class. This class takes the context, and provides all the built in components, based on that context. The only thing you need to provide is a router for Play to route requests to. Below is the simplest application that can be created in this way, using an empty router:

import play.Application;
import play.ApplicationLoader;
import play.BuiltInComponentsFromContext;
import play.LoggerConfigurator;
import play.controllers.AssetsComponents;
import play.db.ConnectionPool;
import play.db.HikariCPComponents;
import play.filters.components.HttpFiltersComponents;
import play.mvc.Results;
import play.routing.Router;
import play.routing.RoutingDslComponentsFromContext;

public class MyComponents extends BuiltInComponentsFromContext
        implements HttpFiltersComponents {

    public MyComponents(ApplicationLoader.Context context) {
        super(context);
    }

    @Override
    public Router router() {
        return Router.empty();
    }
}

And then the application loader:

public class MyApplicationLoader implements ApplicationLoader {

    @Override
    public Application load(Context context) {
        return new MyComponents(context).application();
    }

}

To configure Play to use this application loader, configure the play.application.loader property to point to the fully qualified class name in the application.conf file:

play.application.loader=MyApplicationLoader

In addition, if you’re modifying an existing project that uses the built-in Guice module, you should be able to remove guice from your libraryDependencies in build.sbt.

§Providing a Router

To configure a router, you have two options, use RoutingDsl or the generated router.

§Providing a router with `RoutingDsl`

To make this easier, Play has a RoutingDslComponentsFromContext class that already provides a RoutingDsl instance, created using the other provided components:

public class MyComponentsWithRouter extends RoutingDslComponentsFromContext
        implements HttpFiltersComponents {

    public MyComponentsWithRouter(ApplicationLoader.Context context) {
        super(context);
    }

    @Override
    public Router router() {
        // routingDsl method is provided by RoutingDslComponentsFromContext
        return routingDsl()
                .GET("/path").routeTo(() -> Results.ok("The content"))
                .build();
    }
}

§Using the generated router

By default Play will use the injected routes generator. This generates a router with a constructor that accepts each of the controllers and included routers from your routes file, in the order they appear in your routes file. The router’s constructor will also, as its first argument, accept an play.api.http.HttpErrorHandler (the Scala version of play.http.HttpErrorHandler), which is used to handle parameter binding errors, and a prefix String as its last argument. An overloaded constructor that defaults this to "/" will also be provided.

The following routes:

GET        /                    controllers.HomeController.index
GET        /assets/*file        controllers.Assets.at(path = "/public", file)

Will produce a router that accepts instances of controllers.HomeController, controllers.Assets and any other that has a declared route. To use this router in an actual application:

public class MyComponentsWithGeneratedRouter extends BuiltInComponentsFromContext
        implements HttpFiltersComponents, AssetsComponents {

    public MyComponentsWithGeneratedRouter(ApplicationLoader.Context context) {
        super(context);
    }

    @Override
    public Router router() {
        HomeController homeController = new HomeController();
        Assets assets = new Assets(scalaHttpErrorHandler(), assetsMetadata());
return new router.Routes(scalaHttpErrorHandler(), homeController, assets).asJava();
    }
}

§Configuring Logging

To correctly configure logging in Play, the LoggerConfigurator must be run before the application is returned. The default BuiltInComponentsFromContext does not call LoggerConfigurator for you.

This initialization code must be added in your application loader:

import scala.compat.java8.OptionConverters;
public class MyAppLoaderWithLoggerConfiguration implements ApplicationLoader {
    @Override
    public Application load(Context context) {

        LoggerConfigurator.apply(context.environment().classLoader())
            .ifPresent(loggerConfigurator ->
                loggerConfigurator.configure(
                    context.environment(),
                    context.initialConfig()
                )
            );

        return new MyComponents(context).application();
    }
}

§Using other components

As described before, Play provides a number of helper traits for wiring in other components. For example, if you wanted to use a database connection pool, you can mix in HikariCPComponents into your components cake, like so:

public class MyComponentsWithDatabase extends BuiltInComponentsFromContext
        implements HikariCPComponents, HttpFiltersComponents {

    public MyComponentsWithDatabase(ApplicationLoader.Context context) {
        super(context);
    }

    @Override
    public Router router() {
        return Router.empty();
    }

    public SomeComponent someComponent() {
        // connectionPool method is provided by HikariCPComponents
        return new SomeComponent(connectionPool());
    }
}

Other helper traits are also available as the CSRFComponents or the AhcWSComponents. The complete list of Java interfaces that provides components is:

Next: Application Settings