I am migrating a Play Application from 2.4 to 2.8. I have been successful adapting the application and it runs to some degree, but I am currently stuck with a call to the injector.
The current code reads:
private final TestDB testdb = play.api.Play.current().injector().instanceOf(TestDB.class);
which was the recommended way to go in earlier versions of Play. However, play.Play and play.api.Play have been deprecated since version 2.5: Migration25 - 2.8.x
The next option would be using the guice DI as the migration guide explains by using @Inject, which was already used and working in most of the application. However, from what I understand “Injection from a custom class, which is not injected by itself, should be done by explicit call to the injector” (Code Preference: Dependency injection with Guice in Play) and if I try, then indeed the dependencies are not injected and null is given for those variables. So, if I understand correctly, @Inject is not an option since the class is instanciated outside of the injection mechanisms (in accordance to what I see in the code, it uses “new”)
Since it was mentioned on forums, I tried:
@Inject private play.api.inject.Injector injector; private final TestDB testdb = injector.instanceOf(TestDB.class);
which obviously doesn’t work either, since nothing gets injected, including the Injector.
A parent instance (x calls up) does inject these dependences and as a solution I could pass them along, but I feel there must be a more elegant solution to this. So my actual question is: Is there a way in Play 2.8 to retrieve the injector instance that is used by the application?
Maybe I am missing something very simple, I am rather new to Play and Guice DI, so any help would be greatly appreciated. All the solutions that I found online refer to older versions of play, which do allow direct access to the injector or application objects. The examples from play 2.8 also show how to retrieve the injector, but only in the context of (unit) testing. Also, it is written primarily in Java, rather than Scala.