Deploying Play Framework applications onto WebSphere Liberty Profile

For the past couple of days I’ve been looking into developing enterprise applications in Scala with WebSphere Liberty Profile as the runtime environment (aka application server).

It’s worked fine so far as you can read in two articles of mine:

With so much success (it shouldn’t come as a surprise that at the beginning of a long journey every step is a great success) I’ve been thinking about something a bit more complex that would really demonstrate a production-ready support for Scala in WebSphere Liberty Profile. And all of a sudden a challenge came along – developing Play 2.1 applications with WebSphere Liberty Profile. That was it!

But hey, no built-in support for deploying Play applications onto Java EE application servers?! How could that be? I can understand the point that it’s so much easier to have a hosted runtime environment inside the framework (so it’s just play run to have your application up and running quickly), but there are some valid reasons to deploy the applications onto a full-blown Java EE application server.

You may want to read README in WAR Plugin for Play framework 2.x to find out some of the reasons for “Why choosing WAR packaging when native Play 2 is a better deployment model (features and performances)?”

Speaking of WAR Plugin for Play framework 2.x, that’s the approach people (tend to) recommend when there’s a need to deploy Play applications onto Java EE application servers.

In Server compatibility I couldn’t find any version of WebSphere Application Server and as a matter of fact there was the following sentence: “The plugin may work on others containers, such as Weblogic or Websphere (not tested yet).”

I wore my “entrepreneur” hat and my mission began.

It took a few minutes to have the plugin set up for my simple Play project and dropping the result of play war to the dropins directory of a WebSphere Liberty Profile server was all it took to have the application up and running.

Play's Welcome Page in WebSphere Liberty Profile

No need to do much – play war and cp target/helloplay-1.0-SNAPSHOT.war ~/apps/wlp.next.BETA/usr/servers/defaultServer/dropins did the trick. Easy.

What worried me though was that the page didn’t resemble the look of the page when executed with play run.

Play's Welcome Page in play run

It was way after midnight when I noticed it and was a bit tired to figure it out. Since the exercise was supposed to be quick and easy, I jotted down my findings and scheduled another session with the environment early morning.

That turned out a very productive decision!

After a quarter of self-learning how the sample application worked (created with play new helloplay) the most important piece turned out the app/views/index.scala.html.

@(message: String)

@main("Welcome to Play 2.1") {

    @play20.welcome(message, style = "Java")

}

Note the line @play20.welcome(message, style = "Java"). The page’s source is in welcome.scala.html and what drew my attention was the following line:

@play.api.Play.maybeApplication.filterNot(_.mode != play.api.Mode.Dev).map { _ =>

I knew I nailed it down. When running the application with play run the following was printed out to the console:

[info] play - Application started (Dev)

When the application got started in WebSphere Liberty Profile there was the following line in the logs:

[info] play - Application started (Prod)

That made the difference in the welcome pages. Easy, isn’t it?

BTW, I have not managed to find out how to change Prod to Dev environment for a Play application deployed onto WebSphere Liberty Profile. Anyone?

Be Sociable, Share!
This entry was posted in Frameworks, Languages, WebSphere.

One Response to Deploying Play Framework applications onto WebSphere Liberty Profile

  1. a4835406 says:

    Cannot see the point of giving up on non blocking nature, by reintroducing blocking nature, deploying on was?

Leave a Reply

%d bloggers like this: