[Play! to RePlay migration] play.exceptions.UnexpectedException: Failed to read $PWD/conf/application.conf at startup

[xabolcs]

From the codeborne/replay gitter.im channel:

@xabolcs wrote:

my problem is that it doesn't find the application.conf also the play.plugins in the conf/ directory ... of course as the default play.PropertiesLoader uses the current dir: ./conf/

Using the application plugin (id: 'application') and running the extracted application from the build/distributions/app dir:

$ ./bin/app
Exception in thread "main" play.exceptions.UnexpectedException: Failed to read /app/build/distributions/app/conf/application.conf
	at play.vfs.VirtualFile.inputstream(VirtualFile.java:106)
	at play.libs.IO.readUtf8Properties(IO.java:17)
	at play.PropertiesConfLoader.readOneConfigurationFile(PropertiesConfLoader.java:42)
	at play.PropertiesConfLoader.readOneConfigurationFile(PropertiesConfLoader.java:32)
	at play.PropertiesConfLoader.readConfiguration(PropertiesConfLoader.java:28)
	at play.Play.readConfiguration(Play.java:258)
	at play.Play.init(Play.java:154)
	at com.openseedbox.Application.start(Application.java:23)
	at com.openseedbox.Application.main(Application.java:32)
Caused by: java.io.FileNotFoundException: /app/build/distributions/app/conf/application.conf (No such file or directory)
	at java.base/java.io.FileInputStream.open0(Native Method)
	at java.base/java.io.FileInputStream.open(FileInputStream.java:219)
	at java.base/java.io.FileInputStream.<init>(FileInputStream.java:157)
	at play.vfs.VirtualFile.inputstream(VirtualFile.java:104)
	... 8 more

@xabolcs wrote:

how hard would be to modify PropertiesConfLoader to allow implementing a PropertiesConfLoaderFromResources?
is play.vfs.VirtualFile classpath aware? is able to work with(in) jars?

@asolntsev wrote:

Sure, it's always a good idea to load resources from classpath. I think it should be easy.

---

It would be nice if the RePlay framework would be able to resolve the conf/ directory through the classpath in the case it doesn't exists in the working directory. In that case it would be easy to add conf/ dir to the classpath through the sourceSets.main.resources. The following example fills the resources build directory without defining resources in the project:

// snip

sourceSets {
  main {
    java {
      srcDir "app"
      exclude 'views/'
    }
    resources {
      // no need to define anything
    }
  }
}

// snip

processResources {
  from('conf') {into 'conf'}
  from('app') {include 'play.plugins'}
  from('app/views') {into 'app/views'}
  from('public') {into 'public'}
}

[xabolcs]

I created an example repo to describe my problems: Example project for RePlay! issue #198

It's still in progress, but one could play with

• ./gradlew clean run
• ./gradlew clean distTar jibDockerBuild
  • untar the *.tar from build/distributions/ and try to run it
  • docker run --rm -ti replay-example:issue-198

[asolntsev]

@xabolcs I tried to clone the repo.

1. Command ./gradlew clean run starts, but when I open http://localhost:9000/ in my browser, it causes errors:

   Template not found : /tmp/errors/404.html
   Template not found : /tmp/errors/500.html

2. Command docker run ... throws FileNotFoundException: /conf/application.conf, but when I look into the docker image, I see that it actually doesn't contain folder conf and file application.conf.

[xabolcs]

Thanks for looking into it. It's still in "development" 😅

For the 1. point, it related to #65 (and it's related issues) - I didn't care much for using the empty sample app.
For the 2. point ... well yeah.

The example repo is at a decision point when one have to choose how deal with the old/current behavior - RePlay framework searches $PWD/conf/application.conf at startup ... exaclty what the title of this issue says.

One way to solve this is to "fix" the distribution tasks (the application, the jib, ...) without defining the conf dir as a resource (or even mention it in the processResources task): just do extra steps to copy conf directory in the distribution's working directory - which is isn't easy with dist but very straightforward with jib.

The other way to solve this is to teach the RePlay framework to check not the conf/ folder in the current working directory but to check the conf/ path on the classpath too. Then the solution would be just as easy as creating the conf/ directory in the resources:

• without the Play! directory structure: src/main/resources/conf 😉
• defining '.' as resource but include conf/ only - this is what I did first (SO) - but How Do I Add Multiple Directories And Filter Patterns To A SourceSet?
• exercise processResources task as in the description

So I didn't choose a workaround yet because it could influence the fix itself.

[asolntsev]

@xabolcs It's much simpler than you think.
Take a look at the sample app ("criminals"). It has exactly the same folders' structure as the original Play! projects:

And everything you need to make Gradle support these folder is this piece in build.gradle:

sourceSets {
  main {
    java {srcDir "app"}
    resources {srcDir "app"}
    resources {srcDir 'conf'}
  }
  test {
    java {srcDir "test"}
  }
}

[xabolcs]

It's much simpler than you think.

I thought I tried this "define the app both as java source and resource" thing and my IDEA didn't like it. Sure will retest!
Thanks.