Re: [play-2.1-rc1] Breaks CloudFoundry integration

[James Roper]

The reason for the change is to make the ordering of jars on the prod classpath the same as the dev classpath.  In dev, the classpath is well defined according to dependency ordering, and the current project always takes precedence over its dependencies.  In prod, it was up to the order that the operating system returned the entries on the filesystem.  This particularly caused issues when using sub projects that defined their own application.conf files, in dev mode, the main projects one was always first in the classpath, in prod, it was russian roulette as to which one was first (usually alphabetically ordered).

On Monday, 3 December 2012 07:31:44 UTC+11, Ramnivas Laddad wrote:

Play-2.1-rc1 breaks cloudfoundry integration due to how 'play dist' generates the classpath. 

In play2.0, it generated a simple start script, which meant the additional Cloud Foundry jars that were added to the lib/ directory during application staging will get included in the classpath:

exec java $* -cp "`dirname $0`/lib/*" play.core.server.NettyServer `dirname $0`

Play 2.1 changes to include all dependent jars explicitly, leading to Cloud Foundry jars not being picked up:

scriptdir=`dirname $0`

classpath="$scriptdir/lib/org.scala-lang.scala-library-2.10.0-RC1.jar:$scriptdir/lib/play.play_2.10-2.1-RC1.jar:$scriptdir/lib/play.sbt-link-2.1-RC1.jar:$scriptdir/lib/org.javassist.javassist-3.16.1-GA.jar:$scriptdir/lib/play.play-exceptions-2.1-RC1.jar:$scriptdir/lib/play.templates_2.10-2.1-RC1.jar:$scriptdir/lib/com.github.scala-incubator.io.scala-io-file_2.10.0-RC1-0.4.1.jar:$scriptdir/lib/com.github.scala-incubator.io.scala-io-core_2.10.0-RC1-0.4.1.jar:$scriptdir/lib/com.jsuereth.scala-arm_2.10.0-RC1-1.2.jar:$scriptdir/lib/play.play-iteratees_2.10-2.1-RC1.jar:$scriptdir/lib/org.scala-stm.scala-stm_2.10.0-RC1-0.6.jar:$scriptdir/lib/io.netty.netty-3.5.9.Final.jar:$scriptdir/lib/org.slf4j.jul-to-slf4j-1.6.6.jar:$scriptdir/lib/org.slf4j.jcl-over-slf4j-1.6.6.jar:$scriptdir/lib/ch.qos.logback.logback-core-1.0.7.jar:$scriptdir/lib/ch.qos.logback.logback-classic-1.0.7.jar:$scriptdir/lib/com.typesafe.akka.akka-actor_2.10.0-RC1-2.1.0-RC1.jar:$scriptdir/lib/com.typesafe.config-1.0.0.jar:$scriptdir/lib/com.typesafe.akka.akka-slf4j_2.10.0-RC1-2.1.0-RC1.jar:$scriptdir/lib/org.slf4j.slf4j-api-1.7.2.jar:$scriptdir/lib/joda-time.joda-time-2.1.jar:$scriptdir/lib/org.joda.joda-convert-1.2.jar:$scriptdir/lib/org.apache.commons.commons-lang3-3.1.jar:$scriptdir/lib/com.ning.async-http-client-1.7.6.jar:$scriptdir/lib/oauth.signpost.signpost-core-1.2.1.2.jar:$scriptdir/lib/commons-codec.commons-codec-1.3.jar:$scriptdir/lib/oauth.signpost.signpost-commonshttp4-1.2.1.2.jar:$scriptdir/lib/org.apache.httpcomponents.httpcore-4.0.1.jar:$scriptdir/lib/org.apache.httpcomponents.httpclient-4.0.1.jar:$scriptdir/lib/commons-logging.commons-logging-1.1.1.jar:$scriptdir/lib/org.codehaus.jackson.jackson-core-asl-1.9.10.jar:$scriptdir/lib/org.codehaus.jackson.jackson-mapper-asl-1.9.10.jar:$scriptdir/lib/net.sf.ehcache.ehcache-core-2.6.0.jar:$scriptdir/lib/javax.transaction.jta-1.1.jar:$scriptdir/lib/org.scala-lang.scala-compiler-2.10.0-RC1.jar:$scriptdir/lib/org.scala-lang.scala-reflect-2.10.0-RC1.jar:$scriptdir/lib/helloworld_2.10-1.0.jar"

exec java $* -cp $classpath play.core.server.NettyServer `dirname $0`

Note that the Cloud Foundry staging process replaces play.core.server.NettyServer with a wrapper org.cloudfoundry.reconfiguration.play.Bootstrap that sets up the environment before delegating back to play.core.server.NettyServer. 

So I will like to know if there is some inherent reason for this change (in which case, Cloud Foundry will need to do some extra processing) or could Play2.1 generate the same script as Play 2.0 (in which case, Cloud Foundry integration will just work).

-Ramnivas

[Jean Helou]

Hello, 

I just bumped into this issue and here are the steps I took to make it work anyway : 

- Edit the start script, adding $scriptdir/lib/* after the list of all the jars. this way play dependencies get loaded in the correct order and it still allows for external classes to be injected in the classpath

- Add play-java-jpa as a dependency to my application. Because of the way the trait WithDefaultPlugins works, it will attempt to load classes for what it finds in play.plugins even when the plugin is explicitly disabled in the application conf. Since cloudfoundry currently adds its JPA plugin by default and this plugin depends on play's JPAPlugin, you must add play-java-jpa as a dependency. I haven't found a way to override this and disable a plugin loaded by a jar on the classpath.

Then the instructions on  http://blog.cloudfoundry.com/2012/05/31/cloud-foundry-now-supports-play/ work again even for scala apps which won't need java-jpa.

Cheers,

Jean

[Pradeep Kumar Mishra]

Hi Jean,

Could you please help me with the jpa dependency thing you mentioned. I am not sure how to get this working.

Thank you so much,

Pradeep