No conf folder on the classpath when using ClasspathJarPlugin or LauncherJarPlugin

[gpgekko]

Whenever I try to use either of those plugins, I get the following exception:

Oops, cannot start the server.
Configuration error: Configuration error[application: application.conf: java.io.IOException: resource not found on classpath: application.conf, application.json: java.io.IOException: resource not found on classpath: application.json, application.properties: java.io.IOException: resource not found on classpath: application.properties]

Seems to me that it can't find the conf folder. If I give the application.conf as an argument, it will fail again:

Oops, cannot start the server.
com.google.inject.ProvisionException: Unable to provision, see the following errors:

1. Error injecting constructor, javax.persistence.PersistenceException: No Persistence provider for EntityManager named persistenceUnit

Which seems to indicate it can't find the persistence.xml in the conf/META-INF folder.

I was hoping that with Play 2.4.x I could finally get Windows support again, but it seems both 'solutions' leave me with broken builds...

[muuki88]

Yes, the conf folder is not on the classpath by default. This has security and deterministic reasons. You can add the conf folder to the classpath if you want with

scriptClasspath += "conf/*"

(not tested, check cp syntax). See the docs for this as well.

The other option is to include your persistence.xml inside your application jar, which is on the classpath. This could be done with something like

import NativePackagerHelper._
mappings in Universal ++= contentOf(baseDirectory.value / "META-INF")

[rreimann]

Yes, the conf folder is not on the classpath by default. This has security and deterministic reasons.

I'm not really sure if it is intentional that the conf folder isn't on the classpath. At least for a Play application using the LauncherJarPlugin the MANIFEST.MF of the launcher jar tries to reference the ../conf directory by default.

Manifest-Version: 1.0
Class-Path: ../conf myapplication-1.0-SNAPSHOT-sans-externaliz
 ed.jar org.scala-lang.scala-library-2.11.6.jar ...

As far as i can tell from my test and this blog post regarding manifest classpath syntax the only reason that conf isn't on the classpath is a missing trailing slash that causes the ../conf entry to have no effect. Thus it looks more accidentally than intentionally to me.

Applying the workaround described above with a working classpath syntax scriptClasspath += "../conf/" works for me but leads to multiple conf references (the ineffective default one at the start and the working custom entry from scriptClasspath at the end) in the manifest classpath:

Manifest-Version: 1.0
Class-Path: ../conf myapplication-1.0-SNAPSHOT-sans-externaliz
 ed.jar org.scala-lang.scala-library-2.11.6.jar ...
 ../conf/

[muuki88]

Hm. You are right. I wasn't aware that the LauncharJarPlugin adds this to the classpath. I think this contribution came from the play team. Looks like they had a similar issue.

Applying the workaround described above with a working classpath syntax scriptClasspath += "../conf/" works for me but leads to multiple conf references (the ineffective default one at the start and the working custom entry from scriptClasspath at the end) in the manifest classpath

I don't quite get this. Without the scriptClasspath += "../conf/" you get an exception that no application.conf is found and with you get multiple references?

cc @jroper

[rreimann]

I don't quite get this. Without the scriptClasspath += "../conf/" you get an exception that no application.conf is found and with you get multiple references?

Yes, that's correct but the multiple references don't really hurt since the first one is silently ignored and only the second one works:

1st reference from LauncherJarPlugin: ../conf
2nd reference from scriptClasspath: ../conf/

[jroper]

Let me explain the ../conf/. Play has a mode called externalizeResources, which is enabled by default, where all the resources from the project are not packaged in the jar file, rather, they are put in the conf directory, and the conf directory is added to the classpath. The reason for this is to allow modification of the configuration files, eg, application.conf, in a production deployment without repackaging the application.

So, the simplest work around to this here is to disable it by adding this to your build:

PlayKeys.externalizeResources := false

The solution is to fix Play so that it adds ../conf/ rather than ../conf. So, this has nothing to do with the native packager, rather, the bug is in Play. I've raised it in #4939.

[muuki88]

Thanks James for taking care :)

[Nikitha963]

@jroper I am also facing same issue like above :

[error] stack trace is suppressed; run last Compile / playEbeanModels for the full output
[error] (Compile / playEbeanModels) com.typesafe.config.ConfigException$IO: conf/application.conf: java.io.IOException: resource not found on classpath: conf/application.conf
[error] application - 

! @7jke665m6 - Internal server error, for (GET) [/] ->
 
play.sbt.PlayExceptions$UnexpectedException: Unexpected exception[RuntimeException: com.typesafe.config.ConfigException$IO: conf/application.conf: java.io.IOException: resource not found on classpath: conf/application.conf]
	at play.sbt.run.PlayReload$.$anonfun$taskFailureHandler$1(PlayReload.scala:36)
	at scala.Option.map(Option.scala:163)
	at play.sbt.run.PlayReload$.taskFailureHandler(PlayReload.scala:29)
	at play.sbt.run.PlayReload$.compileFailure(PlayReload.scala:25)
	at play.sbt.run.PlayReload$.$anonfun$compile$3(PlayReload.scala:52)
	at scala.util.Either$LeftProjection.map(Either.scala:573)
	at play.sbt.run.PlayReload$.compile(PlayReload.scala:52)
	at play.sbt.run.PlayRun$.$anonfun$playRunTask$4(PlayRun.scala:77)
	at play.runsupport.Reloader.$anonfun$reload$1(Reloader.scala:413)
	at play.runsupport.Reloader$$anon$1.run(Reloader.scala:51)
Caused by: java.lang.RuntimeException: com.typesafe.config.ConfigException$IO: conf/application.conf: java.io.IOException: resource not found on classpath: conf/application.conf
	at com.typesafe.config.impl.Parseable.parseValue(Parseable.java:188)
	at com.typesafe.config.impl.Parseable.parseValue(Parseable.java:174)
	at com.typesafe.config.impl.Parseable.parse(Parseable.java:299)
	at com.typesafe.config.ConfigFactory.parseResources(ConfigFactory.java:957)
	at com.typesafe.config.ConfigFactory.parseResources(ConfigFactory.java:885)
	at com.typesafe.config.DefaultConfigLoadingStrategy.parseApplicationConfig(DefaultConfigLoadingStrategy.java:49)
	at com.typesafe.config.ConfigFactory.defaultApplication(ConfigFactory.java:473)
	at com.typesafe.config.ConfigFactory$1.call(ConfigFactory.java:259)
	at com.typesafe.config.ConfigFactory$1.call(ConfigFactory.java:256)
	at com.typesafe.config.impl.ConfigImpl$LoaderCache.getOrElseUpdate(ConfigImpl.java:65)
Caused by: java.lang.RuntimeException: java.io.IOException: resource not found on classpath: conf/application.conf
	at com.typesafe.config.impl.Parseable$ParseableResources.rawParseValue(Parseable.java:735)
	at com.typesafe.config.impl.Parseable$ParseableResources.rawParseValue(Parseable.java:710)
	at com.typesafe.config.impl.Parseable.parseValue(Parseable.java:180)
	at com.typesafe.config.impl.Parseable.parseValue(Parseable.java:174)
	at com.typesafe.config.impl.Parseable.parse(Parseable.java:299)
	at com.typesafe.config.ConfigFactory.parseResources(ConfigFactory.java:957)
	at com.typesafe.config.ConfigFactory.parseResources(ConfigFactory.java:885)
	at com.typesafe.config.DefaultConfigLoadingStrategy.parseApplicationConfig(DefaultConfigLoadingStrategy.java:49)
	at com.typesafe.config.ConfigFactory.defaultApplication(ConfigFactory.java:473)
	at com.typesafe.config.ConfigFactory$1.call(ConfigFactory.java:259)

Please help me in resolving this

[muuki88]

Can you provide a minimal example to reproduce this?