Debug not working with play framework activator, scala and eclipse

Question

There are many posts on this, the instructions are straight forward, but for the life of me I can't get the debugger to stop at breakpoints.

My environment is

• eclipse 4.4.1
• scala 2.11
• scala IDE 4.1.0.nightly
• play framework 2.3.3
• play support in Scala IDE 0.4.6

I launch activator as follows

activator -jvm-debug 9999 run

I have set up a remote java application debug configuration with standard socket attach. The debug configuration runs, attaches to the remote and launches a bunch of sbt threads.

But, it will not stop in the debugger! It doesn't seem that hard, what am I doing wrong?

Edit: I have this problem in a project I've been working on for a while and in a brand new, untouched instantiation of the play-anguale-require-seed project. Here is the build.sbt for that project:

import WebKeys._

// TODO Replace with your project's/module's name
name := """play-angular-require-seed"""

// TODO Set your organization here; ThisBuild means it will apply to all sub-    modules
organization in ThisBuild := "your.organization"

// TODO Set your version here
version := "2.3.7-SNAPSHOT"

// Scala Version, Play supports both 2.10 and 2.11
//scalaVersion := "2.10.4"
scalaVersion := "2.11.4"

lazy val root = (project in file(".")).enablePlugins(PlayScala)

// Dependencies
libraryDependencies ++= Seq(
  filters,
  cache,
  // WebJars (i.e. client-side) dependencies
  "org.webjars" % "requirejs" % "2.1.14-1",
  "org.webjars" % "underscorejs" % "1.6.0-3",
  "org.webjars" % "jquery" % "1.11.1",
  "org.webjars" % "bootstrap" % "3.1.1-2" exclude("org.webjars", "jquery"),
  "org.webjars" % "angularjs" % "1.2.18" exclude("org.webjars", "jquery")
)

// Scala Compiler Options
scalacOptions in ThisBuild ++= Seq(
  "-target:jvm-1.7",
  "-encoding", "UTF-8",
  "-deprecation", // warning and location for usages of deprecated APIs
  "-feature", // warning and location for usages of features that should be                 imported explicitly
  "-unchecked", // additional warnings where generated code depends on assumptions
  "-Xlint", // recommended additional warnings
  "-Ywarn-adapted-args", // Warn if an argument list is modified to match the receiver
  "-Ywarn-value-discard", // Warn when non-Unit expression results are unused
  "-Ywarn-inaccessible",
  "-Ywarn-dead-code"
)

//
// sbt-web configuration
// https://github.com/sbt/sbt-web
//

// Configure the steps of the asset pipeline (used in stage and dist tasks)
// rjs = RequireJS, uglifies, shrinks to one file, replaces WebJars with CDN
// digest = Adds hash to filename
// gzip = Zips all assets, Asset controller serves them automatically when client accepts them
pipelineStages := Seq(rjs, digest, gzip)

// RequireJS with sbt-rjs (https://github.com/sbt/sbt-rjs#sbt-rjs)
// ~~~
RjsKeys.paths += ("jsRoutes" -> ("/jsroutes" -> "empty:"))

//RjsKeys.mainModule := "main"

// Asset hashing with sbt-digest (https://github.com/sbt/sbt-digest)
// ~~~
// md5 | sha1
//DigestKeys.algorithms := "md5"
//includeFilter in digest := "..."
//excludeFilter in digest := "..."

// HTTP compression with sbt-gzip (https://github.com/sbt/sbt-gzip)
// ~~~
// includeFilter in GzipKeys.compress := "*.html" || "*.css" || "*.js"
// excludeFilter in GzipKeys.compress := "..."

// JavaScript linting with sbt-jshint (https://github.com/sbt/sbt-jshint)
// ~~~
// JshintKeys.config := ".jshintrc"

// All work and no play...
emojiLogs


fork in run := true

Boelter

Could you show us your build.sbt? – Toucan

You could try Keys.fork in Test := false in your build.sbt, next to fork in run := true. – Toucan

Removing 'fork in run = true' or setting it to false in the build.sbt fixed the problem! – Boelter

Answer 1

Kris' comment has the answer! Remove fork in run from the build.sbt or set it to false. I'm not sure if there will downstream consequences.

Boelter

This should go into the documentation - I was struggling for hours. Thx! – Salvadorsalvadore

This should be the answer :) – Cassilda

not working for me. I create a vanilla scala play project added this to the config restarted everything and connected the debugger... blows right by any breakpoint still. – Isidor

Answer 2

Breakpoints can also be missed when your scala app doesn't always follow java's one-to-one relationship between package and directory structure.

Got bitten by this today with a play framework app. By convention play controllers live in the controllers package. As the project grew it was refactored into several different subprojects. So, controllers directory remained but the package was changed to package controllers.foo, which works fine in scala.

As with the OP, despite the straightforward documentation, nothing worked, debugger would never hit a breakpoint. Once I moved test controller into a directory that matched the package layout, voila, breakpoint hit!

For those that don't use activator, this will start up an sbt debug session:

java -debug -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9999 -jar ~/bin/sbt-launch.jar "$@"

then run run in play console. Switch to Eclipse and select:

• Run > Debug Configurations

• add new Remote Java Application

• choose Standard (Socket Attach), or Scala Debugger (Socket Attach)

• host: localhost, and port: 9999

• click Apply; then click Debug

If all goes well, when you visit a controller with a breakpoint set somewhere in its dependency chain the breakpoint should be hit, thus allowing you to step through the code as expected.

Slesvig

Answer 3

1. Try to run in normal mode and copy paste to your editor your first 2 lines of console's log.
2. Do the same in debug mode.
3. compare :
   • in first line, in debug mode (not in normal) you should have this (with suspend=y):
     agentlib:jdwp=transport=dt_socket,address=127.0.0.1:xxxxx,suspend=y,server=n
   • in debug mode (not in normal) this second line should be present :
     Connected to the target VM, address: '127.0.0.1:xxxxx', transport: 'socket'

suspend=y makes your server waiting to be attached. it could be n

4. inspect your configuration of your remote debugger and inspect the host (localhost) and port (9999) used for listening, and some others options (transport, etc...). It should match with those from the launcher.

Peebles

Thanks for answer - unfortunately it didn't help. The jvm options are reported anywhere that I could find, so I modified the activator script and the option suspend=n. I can see it has effect because the server then waits until the debugger starts. But the debugger still doesn't stop at break points. For completeness, the activator script seems to add these options -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=$1. – Boelter

try to replace in the script: -Xdebug -Xrunjdwp:tnsport=dt_socket,server=y,suspend=n by: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n – Peebles

Unfortunately, this did not help. The debugger still attached to the process, but still did not stop at break points. – Boelter