Appendix

Rowan Laurence
Beyond
Published in
2 min readJan 23, 2018

Part nine of a series

Issues with Guice and Play, and the Play upgrade cycle

When running the application as stage/dist I had massively weird errors in Play. Guice doesn’t say anything other than really meaningless errors about itself.

What do I do?

Cry for hours, search the internet, cry more. Look, and look, and look — finally hack a solution!

There’s no bother explaining this, but essentially Guice loads things when it wants to, and the database connection we have through CharityRepository just keeps telling me that my EbeanServer isn’t there.

The Ebean server is a Singleton, so it means it hasn’t loaded when the CharityRepository loaded.

In CharityRepository.java you can see this line.

This is due to an ordering quirk with the way the classes are being instantiated. If the repository class is created before the EbeanDynamicEvolutions instance and no Ebean server exists, the getServer() method will try to create a server without any config, and subsequently will fail.

Upgrading Play

The one thing that sucks about Play is backwards compatibility, but one of the main things I love is the ‘hold no prisoners’ approach to ditching old concepts — new versions are clean as a whistle.

When you upgrade, you upgrade. You, the coder, has to cope with that. So accept it and keep things small and tested.

At Wowcher we had to deal with the move from Scala Promises to CompletionStages. It took 2 people per week to do so. This is expensive for a . release of a framework.

Now I look back and think, yes it was, but it was the right move. The whole philosophy of breaking on upgrade cycles keeps everyone using the latest features. If you make sure your development teams are working to this upgrade cycle, it’s fine. If you aren’t, it can really hit you hard.

Using Grunt

A lot of people will tell you that they use Gulp over Grunt, or they use NPM directly. For this project I chose Grunt — it’s a doddle to set up and I made some config from some pieces I had laying around in other repos.

The Sass, JS and Image folders are published into the public folder of the Play app and compressed accordingly.

Some files are left behind for ease of debugging, such as the non-minified versions of JS and CSS in the public folders.

To compile and watch for changes on the app, from the front-end folder use:

grunt && grunt watch

Back to the Index

--

--

Rowan Laurence
Beyond
Writer for

Technical Director at Beyond San Francisco — Interested in all things digital, scalable software, collecting shoes and dance music