[2.1 Java] Deployment problems

[Daryl]

I have created a small test project with two subprojects/modules that contain their own routes files included into the main apps routes.

This works fine with either play run or play start. However when I use play stage, or play dist, the routes don't appear to be working correctly. With play stage, the second subproject route appears to work, but not any of the first subproject routes, and none of the public assets are available. With play dist, the first subproject route works, but not the second subproject or any public assets.

After some digging through google groups, and lighthouse ticket, it looks like this might be caused by different classpath's between the two versions. It looks like this might have been fixed, but I am running on the current master branch of Play2 from Github, and I am still seeing these route problems.

Am I doing something wrong, or is this a current bug?

Are there any plans to simplify/improve the deployment options? 

thanks

Daryl.

[Daryl]

This is definitely a classpath problem. 

The start command created by dist, creates a classpath, which lists the modules/subproject jars before the main application jar. If I manually change this classpath to list the application first, before the modules then everything works as expected.

The stage command does not specify a list of jars, just the directory, so I guess this lists the jars in alphabetical order, which will produce random results depending on the module names.

I am about to open a ticket on lighthouse app to report this.

thanks

Daryl.

[James Roper]

Hi Daryl,

play dist should use exactly the same classpath as play run.  We did a fix that we hoped would ensure this.  Maybe it's not the same, if so, that's a bug.

However, the best approach in Play 2.1 to using multiple routes files is to use routes includes.  To do this, in the sub module, name the routes file with a .routes extension, eg myroutesfile.routes.  Then include this in another routes file using:

->  /   myroutesfile.Routes

If you want to run the sub module in isolation to the rest of the app, then in that sub modules application.conf, you can add:

application.router = myroutesfile.Routes

If you do this, classloader issues should not be an issue with routing.

Cheers,

James

[Daryl]

Hi James

Thanks for your reply. This is exactly how I have things set up. My main application has a routes file which includes routes from the two subprojects. My two subprojects are never run standalone so don't have an application.conf.

This works fine in run/start mode, but not in stage or dist. If I change the start script in dist, to move the application jar, before the subproject jars, then it also works. I presume when the subprojects appear first, their routes file is being found, even though it is named as subproject.routes, and has no application.conf.

I will simplify my application and upload to GitHub so that I can raise a lighthouse ticket with a test application that is failing.

Thanks

Daryl.

[James Roper]

I will simplify my application and upload to GitHub so that I can raise a lighthouse ticket with a test application that is failing.

That would be superb.  If routes includes has a bug like that, I would definitely like to fix it before the 2.1 release.

 

Thanks

Daryl.

[Daryl]

Hi James

After some further tidying up, I seem to have fixed the problem of some routes just not working at all. I'm not sure if this was a hangover from upgrading to the RC2 and I was getting something cached from the previous version, but all of the routes seem to be working now.

However, as part of the testing for this, I have found a problem related to the classpath.

If I have the same template/static asset/class in a module, as one in the application (or other module), then there is an inconsistency which version I get. So in Play1, and I would hope this functionality continues, you could have an application overwrite a template from a module. In dev/start mode, this is the case, the application version would be picked up first, replacing the module version.

However when you do a stage/dist, then the classpath must be different, as it is picking up the module version first.

I have created a simple app to demonstrate this:

  https://github.com/bigclumsyoaf/play2-subroutes

In dev/start mode, this will give you a page title of "This is the main template from the app" and a white background colour.

In stage/dist mode, you get "This is the main template from module 1", with a yellow background colour.

If I edit the dist/start script to change the classpath order, making the app.jar appear before the module.jar, then this works as expected. Similarly, if I change the order to find module2.jar first, the message changes to "This is the main template from module2" with a green background.

At the very least the classpath should put the application first. I am not sure how you would then determine the priority of the modules. In Play1, this was controlled by the order of module settings in application.conf, but the SBT build script, only specifies dependencies, not any priorities. If there is a way to specify priorities for the classpath, this would be helpful.

I will raise a lighthouse ticket now, as the module taking preference over the app is definitely a bug for me.

thanks

Daryl.

[Nilanjan Raychaudhuri]

Its good to hear that the routes issue is resolved. Thanks for creating the sample app. I will find out about the ordering of the templates.

Thanks
Nilanjan, Developer & Consultant
Typesafe Inc.