How to fix dependency injection when upgrading pla

2019-08-23 11:46发布

问题:

I am trying to upgrade from play 2.5.x to 2.6.3. (Because 2.5.x doesn't support multipart post in WS. import play.api.libs.ws.DefaultBodyWritables._ throws Exceptions. The code example in the official document doesn't work. The compiler needs the Body Writables which is not provided until 2.6.x)

So I changed the plugin.sbt version to 2.6.3 and upgraded sbt to 0.13.15. And edit the build.sbt file to add guice and json. The project compiles fine. But when I started with sbt run, and visit http://localhost:9000, it throws a bunch of Exception related to a jar file I have in the local lib/ directory. The same code worked just fine with 2.5.x.

Here's the exception:

1) Error injecting constructor, java.lang.NoClassDefFoundError: com/google/common/util/concurrent/FutureFallback at db.ConcreteGGDB.(ConcreteGGDB.scala:24) at Module.configure(Module.scala:29) (via modules: com.google.inject.util.Modules$OverrideModule -> Module) while locating db.ConcreteGGDB

Any idea if this is related to the local jar is not compatible with 2.6.x? or I need to change some code to do dependency injection other than specify in the Module.scala file? Thanks.

回答1:

Why am I getting a NoClassDefFoundError in Java?

Error injecting constructor, java.lang.NoClassDefFoundError: com/twitter/finagle/http/Method$Get$

NoClassDefFound means that there's a class that your code needs, but it can't find it. This typically happens when your project transitively depends on more than one version of a library. For example, imagine that you're building project A, which depends on lib X, and project B, which also depends on lib X. However, project B was built against an older version of lib X, which used to have a class, but which it no longer exports.

A => B => X (version 1)

A => X (version 2)

Then when it runs, A makes a call into B, which tries to make a call into X, but because the project now uses the newer version instead of the older version, it can't find the class it needs.

I would encourage you to use sbt-dependency-graph to see which versions of [library name] you're depending on transitively, and ensure that every library you use uses the same version of [library name].

Looks like an issue with the local jar.