Using SORM with Play Framework causes reflection exceptions to be thrown

Question

I've been trying to get SORM working with Play Framework 2.2-SNAPSHOT as well as 2.1.1. Currently I'm trying to run a minimalistic sample application that I created in order to track down the issue more easily. Unfortunately the error message I receive doesn't help me at all.

val appDependencies = Seq(
    "org.sorm-framework" % "sorm" % "0.3.8",
    "com.h2database" % "h2" % "1.3.168"
)

# Database configuration
#
db.default.driver=org.h2.Driver
db.default.url="jdbc:h2:mem:play"
# db.default.user=sa
# db.default.password=""

case class Car( brand: String, wheels: Int )

object Db extends Instance( Seq( Entity[Car]() ), "jdbc:h2:mem:play" )

object Application extends Controller {
  def index = Action {
    Db.query[Car].count()
    Ok("hello wolrd")
  }
}

Results in this stacktrace:

play.api.Application$$anon$1: Execution exception[[RuntimeException: java.lang.NoSuchMethodError: scala.reflect.internal.TreeInfo.firstArgument(Lscala/reflect/internal/Trees$Tree;)Lscala/reflect/internal/Trees$Tree;]]
    at play.api.Application$class.handleError(Application.scala:289) ~[play_2.10.jar:2.1.1]
    at play.api.DefaultApplication.handleError(Application.scala:383) [play_2.10.jar:2.1.1]
    at play.core.server.netty.PlayDefaultUpstreamHandler$$anonfun$17$$anonfun$apply$24.apply(PlayDefaultUpstreamHandler.scala:326) [play_2.10.jar:2.1.1]
    at play.core.server.netty.PlayDefaultUpstreamHandler$$anonfun$17$$anonfun$apply$24.apply(PlayDefaultUpstreamHandler.scala:324) [play_2.10.jar:2.1.1]
    at play.api.libs.concurrent.PlayPromise$$anonfun$extend1$1.apply(Promise.scala:113) [play_2.10.jar:2.1.1]
    at play.api.libs.concurrent.PlayPromise$$anonfun$extend1$1.apply(Promise.scala:113) [play_2.10.jar:2.1.1]
java.lang.RuntimeException: java.lang.NoSuchMethodError: scala.reflect.internal.TreeInfo.firstArgument(Lscala/reflect/internal/Trees$Tree;)Lscala/reflect/internal/Trees$Tree;
    at play.api.mvc.ActionBuilder$$anon$1.apply(Action.scala:222) ~[play_2.10.jar:2.1.1]
    at play.api.mvc.Action$$anonfun$apply$1$$anonfun$apply$2$$anonfun$apply$5$$anonfun$apply$6.apply(Action.scala:109) ~[play_2.10.jar:2.1.1]
    at play.api.mvc.Action$$anonfun$apply$1$$anonfun$apply$2$$anonfun$apply$5$$anonfun$apply$6.apply(Action.scala:109) ~[play_2.10.jar:2.1.1]
    at play.utils.Threads$.withContextClassLoader(Threads.scala:18) ~[play_2.10.jar:2.1.1]
    at play.api.mvc.Action$$anonfun$apply$1$$anonfun$apply$2$$anonfun$apply$5.apply(Action.scala:108) ~[play_2.10.jar:2.1.1]
    at play.api.mvc.Action$$anonfun$apply$1$$anonfun$apply$2$$anonfun$apply$5.apply(Action.scala:106) ~[play_2.10.jar:2.1.1]
Caused by: java.lang.NoSuchMethodError: scala.reflect.internal.TreeInfo.firstArgument(Lscala/reflect/internal/Trees$Tree;)Lscala/reflect/internal/Trees$Tree;
    at scala.tools.nsc.typechecker.Typers$Typer.parentTypes(Typers.scala:1550) ~[scala-compiler.jar:na]
    at scala.tools.nsc.typechecker.Namers$Namer.templateSig(Namers.scala:861) ~[scala-compiler.jar:na]
    at scala.tools.nsc.typechecker.Namers$Namer.getSig$1(Namers.scala:1300) ~[scala-compiler.jar:na]
    at scala.tools.nsc.typechecker.Namers$Namer.typeSig(Namers.scala:1347) ~[scala-compiler.jar:na]
    at scala.tools.nsc.typechecker.Namers$Namer$$anonfun$monoTypeCompleter$1$$anonfun$apply$1.apply$mcV$sp(Namers.scala:709) ~[scala-compiler.jar:na]
    at scala.tools.nsc.typechecker.Namers$Namer$$anonfun$monoTypeCompleter$1$$anonfun$apply$1.apply(Namers.scala:708) ~[scala-compiler.jar:na]

What a beautiful thing to hear after hours of frustrating trial and error. Thank you for taking care of the issue (: — Taig, Jun 04 '13 at 20:30
Opened [a ticket](https://github.com/sorm/sorm/issues/17). In the mean time please try a previous version `"com.github.nikita-volkov" % "sorm" % "0.3.7"` (note the different artifact group) and report back. It should be working fine. — Nikita Volkov, Jun 04 '13 at 20:35

Nikita Volkov · Accepted Answer · 2013-06-04T21:33:54.967

5

Okay. It's not a bug. SORM 0.3.8 depends on Scala 2.10.1 and Play 2.1.x uses Scala 2.10.0. The exceptions you get are caused by Play mixing artifacts from both Scala versions.

To fix this issue all you need to do is just tell Play to use a proper Scala version by adding scalaVersion := "2.10.1" to project settings in a file project/Build.scala.

The final build script may look like this:

object ApplicationBuild extends Build {

  val appName         = "play-test"
  val appVersion      = "1.0-SNAPSHOT"

  val appDependencies = Seq(
    "org.sorm-framework" % "sorm" % "0.3.8",
    "com.h2database" % "h2" % "1.3.168"
  )

  val main = play.Project(appName, appVersion, appDependencies).settings(
    resolvers += 
      "Local Maven Repository" at 
      "file:///"+Path.userHome.absolutePath+"/.m2/repository",
    scalaVersion := "2.10.1" // <--- ! This is the fix !
  )

}

edited Jun 04 '13 at 21:33

answered Jun 04 '13 at 21:13

Nikita Volkov

42,792
11
94
169

2.10.1 is supposed to be a drop-in replacement for 2.10.0. Could you please elaborate on what exactly causes an exception? upd. Okay, nevermind, I understand now. – Eugene Burmako Jun 04 '13 at 21:21
@EugeneBurmako It was really more of a guess. After giving it more thought, I now believe it may be caused by Play probably having no dependencies on __scala-reflect__ or __scala-compiler__, which SORM currently does have both, so it may turn out that Play mixes __scala-library-2.10.0__ with __scala-reflect-2.10.1__, or something like that. What do you think? – Nikita Volkov Jun 04 '13 at 21:32
Unfortunately I'm still getting a RuntimeException when trying to ```fetch``` an element. ```ClassCastException: __wrapper$1$8dcf00bfeb4549a397715a02daf05008.__wrapper$1$8dcf00bfeb4549a397715a02daf05008$PersistedAnonymous10$1 cannot be cast to [my class]```. Saving items or counting for instance is working now however. – Taig Jun 04 '13 at 23:36
@Taig Fetching works fine on my end. Probably there is a mistake in your code. You can ask a new question. – Nikita Volkov Jun 05 '13 at 00:50
@NikitaVolkov Where does the stack trace come from? Is it from the runtime compilation performed by Sorm? – Eugene Burmako Jun 05 '13 at 06:10
I'm sorry, you're right, it's working. There must be some misconfiguration in my main project. Thanks for your help! (: – Taig Jun 05 '13 at 08:46
@EugeneBurmako I don't know. I don't know what caused it. Taig says it was just his misconfiguration, so whatever. – Nikita Volkov Jun 05 '13 at 09:43
same thing happen when using sorm 0.3.12 with scala 2.10.1 / using scala 2.10.3 with sorm 0.3.12 fixes the bug – Daniel Cukier Feb 06 '14 at 02:38

Using SORM with Play Framework causes reflection exceptions to be thrown

1 Answers1

Linked