Guice Injector Problems upgrading from 2.5 to 2.6 i18n, SessionCookieBaker, FlashCookieBaker


I’m struggling to get a play application to start which is being migrated to play 2.6

My searches to find a solution have failed.

I have extended GuiceApplicationLoader and I’m using play2-maven-plugin

7) No implementation for play.api.i18n.MessagesApi was bound.
  while locating play.api.i18n.MessagesApi
    for the 1st parameter of play.i18n.MessagesApi.<init>(
  while locating play.i18n.MessagesApi
    for the 1st parameter of play.core.j.DefaultJavaContextComponents.<init>(JavaAction.scala:172)
  at play.api.inject.BuiltinModule$$anonfun$$lessinit$greater$1.apply(BuiltinModule.scala:81):
Binding(interface play.core.j.JavaContextComponents to ConstructionTarget(class play.core.j.DefaultJavaContextComponents)) (via modules:$OverrideModule -> play.api.inject.guice.GuiceableModuleConversions$$anon$1)
8) No implementation for play.api.mvc.FlashCookieBaker was bound.
9) No implementation for play.api.mvc.SessionCookieBaker was bound.

I have included the following dependency


A side note: it would be very helpful if play supported maven out of the box - sbt does nothing for the reputation of scala or play tbh

any reason why i18n dependencies are not loaded by Guice?

class DefaultMessagesApi @Inject() (

Is there supposed to be package scanning?. why is the buildin module failing to wire itself up properly

My guess is you need to add the i18nModule somewhere. MessagesApi is now in a separate Play module:

This is included in the default Play reference.conf:

By default, this reference.conf should be loaded as long as the dependency is on the classpath, so it should just work. Are you overwriting play.modules.enabled anywhere in your application.conf, or otherwise manually configuring your Play modules?

A side note: it would be very helpful if play supported maven out of the box - sbt does nothing for the reputation of scala or play tbh

It seems like the Play maven plugin is fairly well maintained, and there’s a Gradle module too as part of the core Gradle distribution. If you have ideas or concerns regarding support for other build systems it’d be valuable to open another discussion thread. It is definitely something the team is interested in.

Thanks Greg, that’s resolved the issue. Really grateful!

The code I’m maintaining had overwritten the play.modules in application.conf

play.modules {
  # By default, Play will load any class called Module that is defined
  # in the root package (the "app" directory), or you can define them
  # explicitly below.
  # If there are any built-in modules that you want to disable, you can list them here.
  #enabled += my.application.Module

  enabled = []
  enabled += play.api.inject.BuiltinModule

The play maven plugin is great, I work in a maven jenkins house. Having to maintain multiple build systems is frowned on. Sbt has given scala and play a bad name at my workplace :slight_smile: impacting adoption.