Scalatra3: The best for Scala on Servlet

Scalatra was one of major web frameworks in early of Scala.

Nowadays, we have a number of modern web frameworks like Play, Finagle, Akka-HTTP or http4s for Scala, and all of them based on non-blocking I/O. Then people says that Scalatra is outdated because it still based on traditional Java servlet’s blocking model. Also since Scalatra has a lot of historical technical debts, actually they has blocked evolution of Scalatra.

From my experience, Scala on Servlet is still necessary in some situation. For example, sometimes we have to use Servlet containers or JavaEE servers because of getting benefits from an existing infrastructure, or introduce Scala partially in existing Servlet or JavaEE based Java systems.

Anyway, now I’m working on the experiment for Scalatra3 which is the next major version of Scalatra from scratch.

Servlet support is the most important requirement in Scalatra. Our first plan of Scalatra3 was port it on http4s because http4s supports non-blocking I/O based backend named blaze and also Servlet based backend. While Scalatra can support Servlet, Scalatra users will be able to choose non-blocking I/O based backend if they need.

However implementing Servlet-like API on http4s was painful beyond my imagination. Blocking processing was needed to implement some APIs. In this situation, use of http4s is meaningless any more. After all, I decided to reimplement Scalatra API on the top of Servlet API directly.


Scalatra3 will eliminate all technical debts and unimportant features in the current code base of Scalatra, and make it easier to maintain. Scalatra3 will keep backward compatibility of major API as much as possible, at least in surface. However most of internal API will be changed.

For example, all unnecessary implicit conversions for fundamental types are removed. If your code depend on extension methods which are provided by such implicit conversion, it won’t work without modification on Scalatra3.

Probably, the biggest change in Scalatra3 is that the action has a return type ActionResult[T]. Scalatra2 allows any types as the result of actions and handle them by inspecting their types. But don’t worry. Since some types are converted to ActionResult[T] automatically, no code changes are necessary in many cases. This change makes it safer and also easier to extends response handling by type classes.

One of new features of Scalatra3 is out-of-box launcher using embedded Jetty. Let me show a tiny example of executable Scalatra application:

import org.scalatra.launcher.ScalatraApp
object HelloApp extends ScalatraApp {
get(“/hello”){
Ok(“Hello World!”)
}
}

You can run this application by sbt run and create an executable jar file using sbt-assembly plugin. This would make it easier to pack your Scalatra application as a docker container. Of course, you can also create a war file and deploy it to any servlet containers or JavaEE servers.


Scalatra3 is still under development and just my experimental project.

However I need the future of Scalatra because I have to keep maintaining Scalatra because my another open source project GitBucket is one of biggest users of Scalatra. GitBucket requires Servlet based web framework to integrate JGitServlet offering Git server functionallity provided as a part of JGit which is pure Java implementation of Git.

I hope that Scalatra continue to be a good choice for Scala on Servlet.