inject
Application lifecycle register.
Application lifecycle register.
This is used to hook into Play lifecycle events, specifically, when Play is stopped. The reason Play only provides lifecycle callbacks for stopping is that constructors are considered the application start callback. This has several advantages:
- It simplifies implementation, if you want to start something, just do it in the constructor. - It simplifies state, there's no transitional state where an object has been created but not started yet. Hence, as long as you have a reference to something, it's safe to use it. - It solves startup dependencies in a type safe manner - the order that components must be started is enforced by the order that they must be instantiated due to the component graph.
Stop hooks are executed when the application is shutdown, in reverse from when they were registered. Due to this reverse ordering, a component can know that it is safe to use the components it depends on as long as it hasn't received a shutdown event.
To use this, declare a dependency on ApplicationLifecycle, and then register the stop hook when the component is started. For example:
import play.api.inject.ApplicationLifecycle import javax.inject.Inject class SomeDatabase @Inject() (applicationLifecycle: ApplicationLifecycle) { private val connectionPool = new SomeConnectionPool() applicationLifecycle.addStopHook { () => connectionPool.shutdown() } ... }
A binding.
A binding.
Bindings are used to bind classes, optionally qualified by a JSR-330 qualifier annotation, to instances, providers or implementation classes.
Bindings may also specify a JSR-330 scope. If, and only if that scope is javax.inject.Singleton, then the binding may declare itself to be eagerly instantiated. In which case, it should be eagerly instantiated when Play starts up.
The binding key.
The binding target.
The JSR-330 scope.
Whether the binding should be eagerly instantiated.
Where this object was bound. Used in error reporting.
The Module class for information on how to provide bindings.
A binding key.
A binding key.
A binding key consists of a class and zero or more JSR-330 qualifiers.
The class to bind.
An optional qualifier.
The Module class for information on how to provide bindings.
A binding target that is provided by another key - essentially an alias.
A binding target.
A binding target.
This trait captures the four possible types of targets.
The Module class for information on how to provide bindings.
The Play BuiltinModule.
The Play BuiltinModule.
Provides all the core components of a Play application. This is typically automatically enabled by Play for an application.
A binding target that is provided by a class.
A binding target that is provided by a class.
The play.api.inject.Module class for information on how to provide bindings.
Default implementation of the application lifecycle.
Default implementation of the application lifecycle.
An injector, capable of providing components.
An injector, capable of providing components.
This is an abstraction over whatever dependency injection is being used in Play. A minimal implementation may only
call newInstance on the passed in class.
This abstraction is primarily provided for libraries that want to remain agnostic to the type of dependency injection being used. End users are encouraged to use the facilities provided by the dependency injection framework they are using directly, for example, if using Guice, use com.google.inject.Injector instead of this.
A Play dependency injection module.
A Play dependency injection module.
Dependency injection modules can be used by Play plugins to provide bindings for JSR-330 compliant ApplicationLoaders. Any plugin that wants to provide components that a Play application can use may implement one of these.
Providing custom modules can be done by appending their fully qualified class names to play.modules.enabled in
application.conf, for example
play.modules.enabled += "com.example.FooModule" play.modules.enabled += "com.example.BarModule"
It is strongly advised that in addition to providing a module for JSR-330 DI, that plugins also provide a Scala trait that constructs the modules manually. This allows for use of the module without needing a runtime dependency injection provider.
The bind methods are provided only as a DSL for specifying bindings. For example:
def bindings(env: Environment, conf: Configuration) = Seq( bind[Foo].to[FooImpl], bind[Bar].to(new Bar()), bind[Foo].qualifiedWith[SomeQualifier].to[OtherFoo] )
A binding target that is provided by a provider class.
A binding target that is provided by a provider class.
The Module class for information on how to provide bindings.
A binding target that is provided by a provider instance.
A binding target that is provided by a provider instance.
The Module class for information on how to provide bindings.
A qualifier annotation.
A qualifier annotation.
Since bindings may specify either annotations, or instances of annotations, this abstraction captures either of those two possibilities.
The Module class for information on how to provide bindings.
A qualifier annotation class.
A qualifier annotation class.
The Module class for information on how to provide bindings.
A qualifier annotation instance.
A qualifier annotation instance.
The Module class for information on how to provide bindings.
A simple map backed injector.
A simple map backed injector.
This injector is intended for use by compile time injected applications in the transitional period between when Play fully supports dependency injection across the whole code base, and when some parts of Play still access core components through Play's global state. Since Play's global state requires that some components are still dynamically looked up from an injector, when using a compile time DI approach, there is typically no way to dynamically look up components, so this provides a simple implementation of the Injector trait to allow components that Play requires to be dynamically looked up.
It is intended to just hold built in Play components, but may be used to add additional components by end users when required.
The injector is an immutable structure, new components can be added using the + convenience method, which returns
a new injector with that component included.
Constructor for a binding Key that doesn't have a qualifier.
Constructor for a binding Key that doesn't have a qualifier.
The Module class for information on how to provide bindings.
Locates and loads modules from the Play environment.
An injector that simply creates a new instance of the passed in classes using the classes no-arg constructor.
Create a binding key for the given class.
Create a binding key for the given class.
The Module class for information on how to provide bindings.
Create a binding key for the given class.
Create a binding key for the given class.
The Module class for information on how to provide bindings.
Play's runtime dependency injection abstraction.
Play's runtime dependency injection support is built on JSR-330, which provides a specification for declaring how dependencies get wired to components. JSR-330 however does not address how components are provided to or located by a DI container. Play's API seeks to address this in a DI container agnostic way.
The reason for providing this abstraction is so that Play, the modules it provides, and third party modules can all express their bindings in a way that is not specific to any one DI container.
Components are bound in the DI container. Each binding is identified by a BindingKey, which is typically an interface that the component implements, and may be optionally qualified by a JSR-330 qualifier annotation. A binding key is bound to a BindingTarget, which describes how the implementation of the interface that the binding key represents is constructed or provided. Bindings may also be scoped using JSR-330 scope annotations.
Bindings are provided by instances of Module.
Out of the box, Play provides an implementation of this abstraction using Guice.
The Module class for information on how to provide bindings.