CODEWITHSUNDEEP
scalaplayframeworksbtplayframework-2.2
nemoo
nemoo

Reputation: 3319

How do i properly configure debug level and ehcache in a play framework dist?

I am using Play Framework 2.2.1 on a linux machine running the universal distribution that is created by calling the dist task.

I am somewhat confused about where and how to configure different aspects of my application in production.

I have these files for configuration:

application.conf
application-logger.xml
ehcache.xml

In the zip file created by the play framework dist task, these files exist twice. 

location 1:
conf/application.conf
conf/application-logger.xml
conf/ehcache.xml

location 2: 
lib/myApp.myApp-1.0-SNAPSHOT.jar/application.conf
lib/myApp.myApp-1.0-SNAPSHOT.jar/application-logger.xml
lib/myApp.myApp-1.0-SNAPSHOT.jar/ehcache.xml

It turns out, application.conf is read from location 1, but application-logger.xml and ehcache.xml are read from location 2!!

So, in order to change the debug level i have to change the content inside of the zip file within the lib folder of my distribution zip?

What am i doing wrong or this the intended design?

Thanks!

Upvotes: 3

Views: 1346

Answers (2)

Jonas Anso
Jonas Anso

Reputation: 2067

Updated answer for Play 2.3.8

You can currently configure the location of you ehcache using ehcache.configResource argument when your start the application.

By default it looks for ehcache.xml and if the file does not exist loads the default configuration provided by the framework ehcache-default.xml

Upvotes: 1

avik
avik

Reputation: 2708

I don't think you're doing anything wrong. I've also been confused in the past at how Play manages configuration in production mode. I believe this is their approach:

  • Files that you include in the conf directory in your project will go into the root of your application JAR. This JAR is then the first JAR on your classpath.

  • These files will also go into the conf directory in your ZIP file. This conf directory however is not added to your classpath, so configuration from these files don't get loaded on application startup.

  • The slight exception is application.conf - before loading this from the classpath, Play will look for it on the filesystem under the conf directory. If it finds it, it'll prefer this version on the filesystem to the version on the classpath.

This explanation is consistent with the behaviour you're seeing. Now coming back to the task at hand, you want to be able to reconfigure your application by changing files on the filesystem rather than hacking JARs. Whilst Play's default behaviour seems to be to hold configuration files in JARs, their production configuration documentation puts forwards different ways to expose your configuration files for easier access:

Exposing your application configuration file

You've found that changes to your application.conf file on the filesystem get picked up by Play, so you don't need to do anything differently. You may nevertheless be interested by the various config.resource, config.file and config.url arguments with which you can start your application.

Exposing your logback configuration file

I generally start my Play applications up with the logger.file argument mentioned in the documentation. Using this argument and pointing to the version of application-logger.xml on the filesystem makes it much simpler to switch on debug-level logging.

Exposing your ehcache configuration file

Exposing ehcache.xml is a bit of a tricky one, as Play currently don't provide a way to load Ehcache configuration from a non-classpath location. What you could do is move your ehcache.xml file here in your project:

dist/ehcache/ehcache.xml

Your ZIP file will then contain it in the following location:

ehcache/ehcache.xml

You can then edit your startup script and add this ehcache directory to your classpath. This should work but is a bit of a manual and ugly approach. There's probably a better way you can get the directory onto your classpath using SBT.

Upvotes: 5

Related Questions