Tag Archives: scala

Play 2 – modules, plugins, what’s the difference?

There seems to be some confusion regarding Play 2 modules and plugins. I imagine this is because the two are often synonymous. In Play (both versions – 1 and 2) there are distinct differences. In this post, I’m going to look at what a plugin is, how to implement one in Java and Scala, and how to import plugins from modules.

Plugins

A Play 2 plugin is a class that extends the Java class play.Plugin or has the Scala trait play.api.Plugin. This class may be something you have written in your own application, or it may be a plugin from a module.

Writing a plugin in Java

Create a new class, and have it extend play.Plugin. There are three methods available to override – onStart(), onStop() and enabled(). You can also add a constructor that takes a play.Application argument.

To have some functionality occur when the application starts, override onStart(). To have functionality occur when the application stops, override onStop(). It’s that simple! Here’s an example implementation which doesn’t override enabled().

package be.objectify.example;

import play.Application;
import play.Configuration;
import play.Logger;
import play.Plugin;

/**
 * An example Play 2 plugin written in Java.
 */
public class MyExamplePlugin extends Plugin
{
    private final Application application;

    public MyExamplePlugin(Application application)
    {
        this.application = application;
    }

    @Override
    public void onStart()
    {
        Configuration configuration = application.configuration();
        // you can now access the application.conf settings, including any custom ones you have added
        Logger.info("MyExamplePlugin has started");
    }

    @Override
    public void onStop()
    {
        // you may want to tidy up resources here
        Logger.info("MyExamplePlugin has stopped");
    }
}

Writing a plugin in Scala

Create a new Scala class, and have it extends play.api.Plugin. Just as in the Java version, there are onStart(), onStop() and enabled() methods along with an play.api.Application constructor argument. Here’s the Scala implementation:

package be.objectify.example

import play.api.{Logger, Application, Plugin}

/**
 * An example Play 2 plugin written in Scala.
 */
class MyExamplePlugin(application: Application) extends Plugin
{
  override def onStart()
  {
    val configuration = application.configuration;
    // you can now access the application.conf settings, including any custom ones you have added
    Logger.info("MyExamplePlugin has started");
  }

  override def onStop()
  {
    // you may want to tidy up resources here
    Logger.info("MyExamplePlugin has stopped");
  }
}

Hooking a plugin into your application

Regardless of the implementation language, plugins are invoked directly by Play once you have added them to the conf/play.plugins file. This file isn’t created when you start a new application, so you need to add it yourself. The syntax is <priority>:<classname>. For example, to add the example plugin to your project, you would use

10000:be.objectify.example.MyExamplePlugin

The class name is that of your plugin. The priority determines the order in which plugins start up, and just needs to be a number that is larger or smaller than that of another plugin. If you have several plugins, you can explicitly order them:

5000:be.objectify.example.MyExamplePlugin
10000:be.objectify.example.MyOtherExamplePlugin

Modules

A module can be thought of as a reusable application that you can include in your own app. It’s analogous to a third-party library that adds specific functionality. A module can contain plugins, which you can hook into your app using the conf/play.plugins file.

For example, if you’re using Deadbolt 2 you would need to add the following to your play.plugins file:

10000:be.objectify.deadbolt.DeadboltPlugin

A list of Play 2 modules can be found on the Play 2 GitHub wiki.

You can read more on creating modules for Play 2 here and here.

Play 2 – some people don’t seem to realise what they have

There’s a very active discussion going on at the moment regarding Play 2 over the Google Group, and it’s really polarising opinion. A lot of people still seem to be under the impression that Play 2 is only a Scala framework, with a crappy half-baked Java API bolted on as an afterthought. It’s not – both Java and Scala are first class citizens in Play 2, and it amazes me that so much FUD is surrounding this issue.

People also seem to be viewing it as a usurper to Play 1, and that Play 1 is now a dead framework walking.

I’m going to do the laziest thing possible in a blog, and reproduce my contribution to this argument (with added emphasis on some parts):

I’ve got projects in production using Play 1.x (including a huge one that took over a year to write – and which would have taken much longer without Play). Do I think Play 1 is going to die? No – because lots of people, including Zenexity, have got lots of projects running on Play 1. For them to let it die would be like shooting themselves in the foot – got this from Guillaume and Sadek directly last night.

Do I want to port those projects over to Play 2? No – because they’re running perfectly well on Play 1, and are now in maintenance mode.

What will I choose for my next project? Probably Play 2, unless the code requires deployment as a war, and this seems to be a point that a lot of people are missing. There’s nothing that can be done in Play 1 that can’t be done in Play 2, and if you want, you can do it all in Java. My Scala is still pretty much at the beginning of the learning process, but this in no way discourages me from coding with Play 2 because *I don’t need to know Scala*. For a comparison, how many people knew Groovy before they started using Play 1 Groovy templates?

Backwards compatibility is important, and that’s why Play 1.2.5 (and .6 and .7 and .n) will be backwards compatible. For Play 2 to not be able to move past what has come before would maybe win some fans in the short term, people who want to be able to drop their Play 1 projects into Play 2 without a code change, but in the mid- to long-term it would have been obsolete before it even started.

There is no Play Scala or Play Java – it’s Play JVM, and that’s what it always has been!

For reference, the thread is https://groups.google.com/d/topic/play-framework/AcZs8GXNWUc/discussion