The Play Team is pleased to announce the release of Play Framework 2.6.13. It is the latest stable release of Play.
What is Play Framework?
Play is a high-productivity Java and Scala web application framework that integrates the components and APIs you need for modern web application development.
Play is based on a lightweight, stateless, web-friendly architecture and features predictable and minimal resource consumption (CPU, memory, threads) for highly-scalable applications thanks to its reactive model, based on Akka Streams.
To upgrade an existing Play 2.6 project, edit your project/plugins.sbt file and set the sbt-plugin to 2.6.13.
To update an older Play project, take a look at the Migration Guide.
Changelog
Play 2.6.13 brings bug fixes, improvements, and dependency updates. The main changes are:
Change Akka HTTP backend to use raw headers: this fixes issues related to HTTP parsing which means Akka HTTP server backend won’t log warnings, won’t reject headers and won’t reformat headers. The fixes here required us to update Akka HTTP to version 10.0.12 (and later 10.0.13), so we recommend that you take a look at the changes made there too.
I just upgraded to 2.6.13 and my debug logs went away in dev. I have had a conf/logback.xml which seems to be ignored now. Is there a migration step somewhere that I missed?
That seems like a bug. @greg, do you have any idea about this? Based on the issue I’d expect it to try logback-test.xml, logback.groovy then logback.xml. Do you have more than one of those in your project? When you say “in dev” do you mean when using sbt run?
@richdougherty Yes, “in dev” I intended to mean sbt run. I do have conf/logback-test.xml in addition to conf/logback.xml. In build.conf to get logback-test.xml to take effect:
javaOptions in Test += “-Dlogger.resource=logback-test.xml”
Perhaps logback-test.xml is taking priority over logback.xml in sbt run?
Adam seemed like he was having a similar issue. I decided to downgrade to 2.6.12 and it works fine! I also tried -DLogger.file and that worked but it tried to load both which was weird.
So if you have both a logback.xml and a logback-test.xml file on your classpath, the logback-test.xml file should take precedence. Normally that’s fine since you’d have that file in your test/resources so it wouldn’t be on the classpath except in test.
Moving logback-test.xml to test/resources did seem to work for test logging. I still have no debug logging and assume it is because I have a conf/logback-prod.xml which is now taking priority. On production, I am enabling production logging with this which I assume is a pretty standard thing to do:
-Dlogger.resource=logback-prod.xml
Is there another place other than conf I must move my logback-prod.xml file to so that it still takes effect without having to change my production environment?
(I also feel this is a non-backwards compatible change and should be immediately reverted from the patch level release before it can cause anyone trouble. It is pretty clear at this point that new users are opening stackoverflow on it and existing users need changes from how things have worked for many years. Migration steps and some official documentation in the next major release would be best.)
It is possible to have a logback-play-dev.xml and logback-play-default.xml for dev and prod confs respectively. Those will be overridden by any of the standard logback configuration files (logback-test.xml, logback.groovy, logback.xml, etc. if they exist). It’s probably less confusing to stick with the standard logback behavior and manually override though.
I don’t have a strong opinion on reverting, but I would consider the change in 2.6.13 to be a bugfix. If a user was using logback-test.xml that’s probably because they’re following the logback convention, and the logback convention is to always favor logback-test.xml over logback.xml if it is on the classpath. I know from the issues reported and my own personal experience that many other people had to hack things because Play didn’t follow the convention.
Perhaps to improve backwards compatibility we could make logback-test.xml only take effect in Test mode? This differs from the standard configuration but allows it to work for the typical use case.
I tried changing conf/logback.xml to conf/logback-play-dev.xml and conf/logback-prod.xml to conf/logback-play-default.xml but still have no dev mode (sbt run) debug messages. I have no other xml files in my conf directory other than an ehcache.xml file (i moved logback-test.xml to test/resources which seems fine). I tried just having conf/logback.xml (without any conf/logback-prod.xml) but that actually doesn’t give me debug messages either. I feel like my setup in 2.6.12 followed what is officially documented and if what you are suggesting worked then it should probably be documented there too.
I turned on -Dlogback.debug=true and see nothing about my conf/logback.xml…only a bunch of
20:57:31,656 |-INFO in ch.qos.logback.classic.LoggerContext[default] -
Found resource [logback-test.xml] at
[jar:file:/C:/Users/Adam/.ivy2/cache/com.typesafe.play/play-openid_2.12/jars/play-openid_2.12-2.6.9.jar!/logback-test.xml]
Is it possible that some play-openid jar with logback-test.xml in it is what is being used over my conf/logback.xml?
It sounds like you are saying that it isn’t a good idea for anyone to upgrade to 2.6.13 unless all dependencies they use are first confirmed to have already updated to 2.6.13. I hate to speculate but I do include play-silhouette and I think it uses play-openid and is built with play 2.6.9. It makes me uncomfortable that I can’t upgrade a patch version of playframework without action on the part of 3rd party dependencies that I don’t control. I feel like that is a definitive reason why this change can’t be considered backwards compatible and must be backed out and put in a major release change along with proper migration steps and official documentation about logback-test.xml needing to move to test/resources and build.sbt test include convention no longer necessary, logback.xml needing to change to logback-play-dev.xml, logback-prod (or equivalent) changing convention to logback-play-default.xml.
I see where you’re coming from, but keep in mind that the release has already happened. It’s now a breaking change to break the default behavior. I’d like to minimize any changes if possible. Like I said, a more conservative change would be to have logback-test.xml only apply in Test mode.
You shouldn’t always have to update to the latest version of every Play dependency, but it’s often a good idea especially if a bug affects you. In this case the logback-test.xml bug in play-openid affects more people because Play now follows the standard logback loading behavior. So effectively one bug was obscuring the fact that another existed. Either way, the ideal solution is to upgrade libraries.
Other Play contributors may disagree with my opinion here, but the nonstandard logback-test.xml bug affected me and I was happy to get it fixed, and I’m sure others felt the same. If we simply revert that change I’m worried it would cause more frustration and confusion.
Perhaps a good solution for Play 2.6.14 would be to display a warning if there is more than one log configuration found on the classpath, listing the files and then stating which configuration file was selected. This will help people who have more than one log configuration debug the issue, since it will usually be unintentional and it’s hard to debug log configuration issues.
Or we could link to a page explaining the problem if we see a logback-test.xml in Dev mode. Most likely the issue is play-openid so we should mention that.
