The Play! Framework offers a new way to develop web applications. Relying on a stateless model, a light but complete stack and no big turnaround times for debugging, Play! makes developing Scala applications really efficient. akquinet is using Play! in several projects. But, what makes Play! even better and your development even more efficient is the Scala support. You can develop your application using the Scala language.
This blog post explains how to set up Play! and your development environment to develop web applications efficiently. It covers the Play framework and the Scala module installation, the integration inside the Eclipse IDE, the Source Code Management configuration and the deployment into Apache Tomcat and JBoss AS.
Play and Scala setup
First, you have to download the Play framework from http://www.playframework.org/download
. Unzip the archive to a folder. We’ll call that folder PLAY_HOME from now on.
$ wget [http://download.playframework.org/releases/play-1.2.2.zip] $ unzip play-1.2.2.zip $ cd play-1.2.1 $ export PLAY_HOME=`pwd`
Play itself is already nice, but we add a little extra and use Play together with Scala. So we have to install the Scala module to activate the Scala support for Play.
$ cd $PLAY_HOME $ ./play install scala
Now I can create my first application with
$ ./play new helloworld --with scala
Yes, that’s all. Enter the start command
$ ./play run helloworld
and in your favorite internet browser you can open http://localhost:9000/ and see your application running.
Scala and IDE
Now you can edit the code and start developing, but I like to have some support during the development. Of course you can install the Scala syntax highlighting for vim from http://lorenzod8n.wordpress.com/2008/01/11/getting-scala-syntax-hightlighting-to-work-in-vim/, but sometimes you like to have a little more integrated environment. That means IDE support, a Source Code Control System, deployment, continuous integration and all that stuff. This post covers IDE integration and source code control. The continuous integration will be covered later in another post.
First: it’s nice to have IDE support. We use Eclipse, therefore we install the Scala plugin for Eclipse from http://www.scala-ide.org/ and run:
$ cd helloworld/ $ ../play eclipsify
Fine, now I can import my project into Eclipse as an existing project. The current version (Play version 1.2.2 and Scala module 0.9.1) generates code from the HTML files and uses it in the controllers like
import views.Application._
The code is stored in a local tmp directory, therefore we had to add the directory tmp/classes as a class folder to the project build path. From here we just code our project, save it and immediately see the results in the browser – no big turn around…
Source Code Management
The next step is to have a Source Code Management system. At the moment we use subversion and git (depending on the project). In this post we use git, but using any other SCM technology is pretty straightforward. Normally I would simply add the project to a git repository. Still in the project folder
$ git init $ git add * $ git commit -a -m “initial checkin”
Fine, from here you can work as usual. But the first time you share your project with another developer, you’ll encounter a problem. If a Play project uses a dependency, Play creates a module directory and puts a file for every dependency in that directory. The content of the module directory is
m4500 6 (helloworld) >ls -al modules/ insgesamt 12 drwxr-xr-x 2 rmagnus rmagnus 4096 2011-06-22 23:39 . drwxr-xr-x 11 rmagnus rmagnus 4096 2011-06-28 09:52 .. -rw-r--r-- 1 rmagnus rmagnus 55 2011-06-22 23:39 scala-0.9.1 m4500 7 (helloworld) >cat modules/scala-0.9.1 /home/rmagnus/projects/play-1.2.2RC1/modules/scala-0.9.1
There is an absolute path stored here which does not work for other workspaces. So we changed the content of modules/scala-0.9 from
/home/rmagnus/projects/play-1.2.2RC1/modules/scala-0.9.1
into
./modules/scala-0.9.1
Deployment
The next step would be the deployment. Play itself offers a really good http server, but most production systems already have an application server and you don’t want two servers on one system for the same reason. So I have to deploy the application into an existing application server. In this post we cover Apache Tomcat and JBoss Application Server.
The first thing we need is a deployable war file. Play provides a way to build a complete war file embedding all dependencies:
$ cd $PLAY_HOME $ mkdir deploy $ ./play war helloworld -o deploy/helloworld
The original example on the Play website says ‘-o helloworld.war’ – but don’t get confused. The result isn’t a file, it’s a directory.
Apache Tomcat
Now we copy the directory to the Apache Tomcat webapps folder
cp -avu deploy/helloworld ~/env_dev/apache-tomcat-5.5.26/webapps/
and check the Tomcat output
03.07.2011 22:12:45 org.apache.catalina.loader.WebappClassLoader validateJarFile INFO: validateJarFile(/home/rmagnus/env_dev/apache-tomcat-5.5.26/webapps/helloworld/WEB-INF/lib/geronimo-servlet_2.5_spec-1.2.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class 22:12:45,155 INFO ~ Starting /home/rmagnus/env_dev/apache-tomcat-5.5.26/webapps/helloworld/WEB-INF/application 22:12:45,156 INFO ~ Module scala is available (/home/rmagnus/env_dev/apache-tomcat-5.5.26/webapps/helloworld/WEB-INF/application/modules/scala-0.9.1) 22:12:45,808 INFO ~ Application is precompiled 22:12:46,012 INFO ~ Application 'helloworld' is now started !
that’s it for Apache Tomcat. If you want to configure your artifact, create a ‘war/WEB-INF’ directory in your application. Here you can put additional configuration files. We’ll need this for the JBoss AS example.
JBoss Application Server
The current Play version (1.2.2 with Scala modul 0.8.1) produces a NullPointerException in the ScalaTemplate class in JBoss – so I have to run this example with Play version 1.2.1.
We’re using JBoss AS 6.0. But here we have to add an additional file to prevent JBoss from scanning the application annotation (see https://issues.jboss.org/browse/ISPN-1046).
$ mkdir -p helloworld/war/WEB-INF $ vim helloworld/war/WEB-INF/jboss-scanning.xml
The content of jboss-scanning.xml is simple
<scanning xmlns="urn:jboss:scanning:1.0"> <!-- Purpose: Disable scanning for annotations in contained deployment. --> </scanning>
Let’s create the artifact again and copy it to the JBoss.
$ cd $PLAY_HOME $ mkdir deploy $ ./play war helloworld -o deploy/helloworld.war $ cp -avu deploy/helloworld.war/ ~/env_dev/jboss-6.0.0.Final/server/default/deploy/
The extension ‘.war’ is very important here! Otherwise JBoss will not recognize the application as an exploded war archive and will not process the jboss-scanning.xml file and we’ll get a lot of errors. So using ‘<application>.war’ as the naming pattern for your output directory seems to be good practice.
After copying it, JBoss AS is writing some good news:
18:09:31,975 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/helloworld 18:09:32,130 INFO [STDOUT] 18:09:32,129 INFO ~ Starting /home/rmagnus/env_dev/jboss-6.0.0.Final/server/default/deploy/helloworld.war/WEB-INF/application 18:09:32,131 INFO [STDOUT] 18:09:32,131 INFO ~ Module scala is available (/home/rmagnus/env_dev/jboss-6.0.0.Final/server/default/deploy/helloworld.war/WEB-INF/application/modules/scala-0.9) 18:09:33,184 INFO [STDOUT] 18:09:33,183 INFO ~ Application is precompiled 18:09:33,231 INFO [net.sf.oval.Validator] gnu.trove collection classes are available. 18:09:33,322 ERROR [STDERR] SLF4J: Class path contains multiple SLF4J bindings. 18:09:33,322 ERROR [STDERR] SLF4J: Found binding in [vfs:/home/rmagnus/env_dev/jboss-6.0.0.Final/common/lib/slf4j-jboss-logmanager.jar/org/slf4j/impl/StaticLoggerBinder.class] 18:09:33,322 ERROR [STDERR] SLF4J: Found binding in [vfs:/home/rmagnus/env_dev/jboss-6.0.0.Final/server/default/deploy/helloworld.war/WEB-INF/lib/slf4j-log4j12-1.6.1.jar/org/slf4j/impl/StaticLoggerBinder.class] 18:09:33,323 ERROR [STDERR] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. 18:09:33,412 INFO [STDOUT] 18:09:33,412 INFO ~ Application 'helloworld' is now started !
Again – that’s it, very nice.
There is one thing that is a little bit annoying: The lib directory for the application is 47MB and contains a lot of libraries which you don’t really need in a JBoss environment, like org.eclipse.jdt.core-3.6.0.jar and scalatest-1.2-for-scala-2.8.0.RC7-SNAPSHOT.jar. We hope there’ll be a way around this in the future.
Conclusion
This post has presented how you can start efficiently developing web applications using the Play! framework and Scala. It has covered the installation and configuration of Play!, the IDE and SCM management and the deployment into a production server (Apache Tomcat and JBOSS AS 6.0). Thanks to these tips, you’re now able to develop a nice web application and go live pretty fast. Another blog post will present how this ‘live’ deployment can be automated using a continuous integration server such as Jenkins.
2 thoughts on “Start developing Play! applications with Scala”
Comments are closed.