Re: staged project won't start - Configuration error: Configuration error [Cannot connect to database [default]]

[Nick Fisher]

Do you have an instance of your MySQL database on the remote server that is running your Play application, or does the database live on a different server?  If it's a different server, you need to change the localhost value of db.default.url to the IP address or hostname of the server hosting MySQL.

On Sunday, November 4, 2012 2:02:19 PM UTC-5, toniObject wrote:

Hi all,

I created a start script by executing the stage task. Calling the start script on my local machine causes no problem, but on the remote machine it won't start the play server. I get this error:

Play server process ID is 8518

SLF4J: Class path contains multiple SLF4J bindings.

SLF4J: Found binding in [jar:file:/root/.jenkins/jobs/PNG/workspace/target/staged/slf4j-jdk14-1.6.4.jar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: Found binding in [jar:file:/root/.jenkins/jobs/PNG/workspace/target/staged/logback-classic.jar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.

Oops, cannot start the server.

Configuration error: Configuration error [Cannot connect to database [default]]

at play.api.Configuration$.play$api$Configuration$$configError(Configuration.scala:71)

at play.api.Configuration.reportError(Configuration.scala:258)

at play.api.db.BoneCPPlugin$$anonfun$onStart$1.apply(DB.scala:249)

at play.api.db.BoneCPPlugin$$anonfun$onStart$1.apply(DB.scala:240)

at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:194)

at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:194)

at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:59)

at scala.collection.immutable.List.foreach(List.scala:45)

at scala.collection.TraversableLike$class.map(TraversableLike.scala:194)

at scala.collection.immutable.List.map(List.scala:45)

at play.api.db.BoneCPPlugin.onStart(DB.scala:240)

at play.api.Play$$anonfun$start$1.apply(Play.scala:60)

at play.api.Play$$anonfun$start$1.apply(Play.scala:60)

at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:59)

at scala.collection.immutable.List.foreach(List.scala:45)

at play.api.Play$.start(Play.scala:60)

at play.core.StaticApplication.<init>(ApplicationProvider.scala:51)

at play.core.server.NettyServer$.createServer(NettyServer.scala:133)

at play.core.server.NettyServer$$anonfun$main$5.apply(NettyServer.scala:162)

at play.core.server.NettyServer$$anonfun$main$5.apply(NettyServer.scala:161)

at scala.Option.map(Option.scala:133)

at play.core.server.NettyServer$.main(NettyServer.scala:161)

at play.core.server.NettyServer.main(NettyServer.scala)

I doubt that the db configuration is wrong because it works fine when the server is started by the command "play start" or "play debug ~run". As I mentioned before the start script created by the stage task works well on local machine. Any idea what could I could check?

P.S. This is a snippet for the db configuration:

db.default.driver=com.mysql.jdbc.Driver

db.default.url="jdbc:mysql://localhost:3306/fu"

db.default.user=foo

db.default.password=bar

[James Roper]

You might be encountering the non deterministic classloader issue.  Do you have multiple sub projects?

On Thursday, 8 November 2012 19:48:29 UTC+11, toniObject wrote:

Hi Nick,

The mysql DB is on the same server as the playframework. I think that the play config is correct, because "play start" works well without any errors. 

[toniObject]

Hi James,

There is exactly one project. What is the non deterministic classloader issue?

[James Roper]

In Play 2.0.x, the order of dependencies on the classpath is different between dev and prod.

We probably need better debugging utilities here, but try writing a plugin (implement the Plugin interface) that looks up the database configuration and logs it to standard out.  Create a file called play.plugins, put it in your conf directory, and put the text "1:package.of.MyPlugin" in it.  Now in dev, that should log your database configuration on startup before anything else happens.  In prod, it should do the same.  This will confirm whether Play is using the database configuration you're expecting it to use.

[virtualeyes]

What's the deal with this in 2.1, still a sub projects issue?

Have 10 sub projects, connect to db just fine dev mode, but when trying to start on staging server db connection instantly fails:

Configuration error[Cannot connect to database [default]]

wtf, I know it works since I copied over existing play 2.1 (non sub project enabled) production application, modified prod.conf and pointed it to staging database and connected without issue. Can also connect via mysql client to remote staging db, so the problem is in the application itself.

Was surprised to see no prod.conf in dist generated jar (i.e. with top level lib/, logs/, start), have to assume that aggregator project's prod.conf is being used, but god knows, difficult to debug to say the least.

Have wasted the better part of the afternoon on this, would appreciate feedback from anyone who has 2.1 sub projects working in production/staging with a database.

Thanks

[virtualeyes]

Got this sorted but not sure if there's a bug here with 2.1 sub project enabled builds.

Check it out, when I generate the application for deployment:
play -Dconfig=/abs/path/conf/prod.conf dist

First, no prod.conf is created in generated zip file at top level with lib/, logs/, and start, which means you have to include that step as part of deploy process.

Second, if you don't specify -Dconfig, good luck getting your prod.conf in above dist task recognized. You have to add to your ./start command config options:
-Dconfig.file=/abs/server/path/to/application/prod.conf

This may be blindingly obvious, but never had to specify prod.conf location in previous 2 non-subproject enabled production play projects, was picked up automatically.