Play framework in an enterprise environment

I've been given the task of evaluating how well a play framwork application can fit inside an enterprise environment. And it is very "enterprise". We are talking maven artifacts, webservices, data models, spring and EJBs to the left and right and preference in terms of application servers, build scripts, development environments. And not to mention, large legacy code base that is "expensive" to touch.

So why the play framework? Well, to put it simple, web development in this environment is very clumsy to work with and time consuming (read: expensive) to work with. The evaluation of play framework is seen as an opportunity to reduce cost for simple GUI development. And perhaps even the developers will get motivated and ambitious again.

The points to evaluate are these:

• Play 2 (Java)
• Maven. Both builds and dependency management.
• Dependency management (yes, SBT can pick up deps from our nexus)
• Spring. Loading beans in dependencies.
• Web service clients, mainly axis (maybe only)
• EJBs. Both weblogic and JBoss.
• JBoss AS 7

We'll see how far I get before I get other assignments...

Play 2, first impressions

I have two first impressions of the play framework.

1. They've really decided to go their own way with Java web development, which is good, since we need a faster way of building these kinds of systems.
2. It static. I'm talking about the java reserved word static. I've always hated it for various reasons I will not take up here. But I guess I'll have to deal with that.

Maven

There is a play2-maven-plugin which seems to handle everything judging from their homepage.

Building

I have tried running the project with maven, which works fine. However you will not get away from having a local play2 installation, which kind of complicates the work at the CI servers. This is the reason why we have maven, all our builds work everywhere there is maven and java. But not with play.

Dependencies

Play framework v2 uses the sbt (build tool for scala?) build system. For all the maven and ivy users out there this is great news, because sbt speaks maven. To add your dependencies to the project you can add them to the pom.xml. But it seems to me that that is not what matters most. You need to add them to the project/Build.scala file. Otherwise it wont work. You also need to add your internal repositories here, if needed. After having updated the Build.scala, you need to run play eclipsify or similar depending on your favourite IDE.

References

http://cescoffier.github.com/maven-play2-plugin/maven/snapshot/ 

Spring

The spring4play2 module makes this work just fine. You can use spring just like you do in any application. However, since play2 @Autowired or @Inject does not work anymore, maybe they'll show up later. And you cannot make play pick up ordinary controllers from Spring, as they are static. There are ways to do this but it complicates the structure of the application a little bit. I would have prefered if you could point Play to always get controllers from Spring, like the Spring object factory in Struts 2. As a small sidenote, the Spring4Play2 module does not seem to work with Play 2.1.

References

https://github.com/scott-phillips/Spring4Play2/blob/master/README.markdown

EJBs

Once the spring integration was proven useful the simplest way to wire in EJBs is through spring. This turned out to be too painful a task to finish off. In my case, we run JBoss AS 7, which would mean that we "only" need to add the jboss-as-client dependency and we should be ready to go. This is not the case. SBT freaks out due to the massive complexity of all the dependencies and whatnot that comes with the jboss-as-client. I wont spend any more time on this but "dream" back to the days we ran weblogic and had a manually composed jar based on the gigantic weblogic.jar that we added to our applications with maven.
You could probably do the same thing for JBoss. And it would probably work. But I'm giving up.

Web service clients

Simple enough. This is just a client library. We build and manage them with maven. Just add your deps and you are ready to go!

JBoss AS 7

One of the most important points. Can I run the application in JBoss? Well, yes you can, but with play framework version 2.0 you can only run it in the root context, but this should be possible with 2.1 [reference needed]. From the threads I read through I get the impression that play 2 isn't ready for the traditional enterprise environment yet.

References

https://play.lighthouseapp.com/projects/82401/tickets/8-war-packaging
http://stackoverflow.com/questions/12915199/deploy-play-2-app-to-jboss-7

Conclusion

I must say that play is a truly new take on web development for Java and the JVM. It feels like a trendbreaker. The very generic approach of Java tools has prevented easy and fast web development. Play framework is the answer to this. However, in the very complex existing enterprise environments the web systems must fit in. Web frontends must be able to speak with present components and systems using present integration technologies. Which it isn't really ready for. The technological hassle to go through to get things running can become costly and introduce too much risk. It might not be worth the effort.

Heres another writeup on the Play Framework 2 which touches similar points.
http://ricardozuasti.com/2012/web-development-frameworks-part-2-play-framework-2-0/

Simple session and request scopes for spring unit tests

I've ran into this several times before and today it happened again. You get a message like this

java.lang.IllegalStateException: No Scope registered for scope ‘session’

when running spring managed unit tests on your spring managed beans.


I remember having created a complex solution the last time for this issue. But today I found this blog entry. What you do is to register

org.springframework.context.support.SimpleThreadScope  

for the session and request scope using the

org.springframework.beans.factory.config.CustomScopeConfigurer 

bean. The technical details are outlined in the blog post, you can read that entry for yourselves. This solution is much more pretty than my old one that you can find in some of my old sources on github. The original idea comes from here, but that blog seems to be borken.