Play 2.6.0-M1 released!

117 views
Skip to first unread message

Greg Methvin

unread,
Feb 16, 2017, 1:06:57 AM2/16/17
to play-framework, Play framework dev
Hi all,

The Play team is proud to announce the first milestone of Play 2.6.0. Like all milestone releases, the main goal is to get feedback, so please let us know if something isn't working or you see something that should be improved.

If you are the author of a Play module, we would recommend checking out this release to see how it will affect your module.

The most important change in this milestone is to remove the requirement for a static application (Play.current) for your application to work. The goal is that your application is completely self contained, allowing you to run and test more than one application at the same time without them interfering with each other. This does not apply if you use deprecated features.

You can see a summary of our progress on 2.6.0 in our roadmap document.

Play 2.6.0 supports both Scala 2.12 and Scala 2.11. Akka HTTP is now the default HTTP server. The Netty server is still supported and uses Netty 4.1. This release does not have support for HTTP/2 yet, but that will be coming in a future milestone.

Several Play modules have been split into standalone projects, without Play dependencies:
  • play-json has been moved to a separate project with its own release cycle and Scala.js support.
  • play-ws also now has a standalone version that can be used outside of Play.
  • play-iteratees now contains the iteratees library and its reactive streams implementation
Guice support (play-guice) and Java forms (play-java-forms) have also been modularized, but with the same versioning and release cycle as the rest of Play.

Please see the migration guide for details on how to upgrade from 2.5.x. We especially value your feedback (and pull requests) on how to make upgrading to this release as smooth as possible.


The following libraries have already been upgraded to support this release:
  • anorm: 2.6.0-M1
  • play-ebean: 4.0.0-M1
  • play-slick: 3.0.0-M1 (no Scala 2.12 support yet)
  • scalatestplus-play: 2.0.0-M2
  • play-mailer: 6.0.0-M1

Please note that this is intended to be a preview of the 2.6.0 release and we would not recommend using this release in a production application. We have made an effort to introduce most major API changes in this release, but we reserve the right to break everything in a future milestone or release candidate. The good news is that there’s still a chance to provide feedback, so please try it out and let us know what you think. Don’t hesitate file issues on the project or start a discussion on the mailing list if you have suggestions.

--
Greg Methvin
Tech Lead - Play Framework

Christopher Hunt

unread,
Feb 16, 2017, 1:20:04 AM2/16/17
to Greg Methvin, play-framework, Play framework dev
Congratulations Play Team! This looks like an impressive release.

Very well done.

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Christopher Hunt
Technical Lead, Lightbend Production Suite
@huntchr
UTC+11

Felipe Alfaville

unread,
Feb 16, 2017, 5:38:46 AM2/16/17
to Play Framework, play-fram...@googlegroups.com
Congratulations Play Team! 

 
Felipe Alfaville
Analista de Sistemas
Contato: (86) 99416-6936

bpo

unread,
Feb 16, 2017, 11:54:14 AM2/16/17
to Play framework dev, play-fr...@googlegroups.com
Hi,

Congratulations for the release but it failed on dependency checking

[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] ::          UNRESOLVED DEPENDENCIES         ::
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: com.typesafe.play#play-omnidoc_2.12;2.6.0-M1: not found
[warn] ::::::::::::::::::::::::::::::::::::::::::::::

Viktor Klang

unread,
Feb 16, 2017, 12:05:17 PM2/16/17
to Greg Methvin, play-fram...@googlegroups.com, play-fr...@googlegroups.com
Congratulations!

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.

Greg Methvin

unread,
Feb 16, 2017, 5:50:28 PM2/16/17
to play-framework, Play framework dev
To answer the questions on this thread:

play-slick 3.0.0-M2 has now been released with Scala 2.12 support: https://oss.sonatype.org/content/repositories/releases/com/typesafe/play/play-slick_2.12/3.0.0-M2/

Matthias Kurz

unread,
Feb 17, 2017, 7:32:54 AM2/17/17
to Play framework dev, play-fr...@googlegroups.com

Christian Schmitt

unread,
Feb 17, 2017, 9:19:28 AM2/17/17
to Play Framework, play-fram...@googlegroups.com
> Is it possible now to run a play app without a runtime dependency injection framework at all and only rely on compile-time DI?

yes

> I presume the actour system can be retrieved from the app in the application builder and given as standard constructor parameter to the component? 

> If I am not wrong it will be good to add this in the migration method for all the people using compile-time DI.

In 2.5 you already could use BuiltInComponents trait, which actually had the actor system defined for your.

https://www.playframework.com/documentation/2.6.x/ScalaCompileTimeDependencyInjection#Application-entry-point

sadly we have no example project for mac wire, but it's actually extremly simple.
Just define your ApplicationComponent which mixes in Components you need/created


Am Freitag, 17. Februar 2017 11:03:25 UTC+1 schrieb Mariot Chauvin:
Hi Greg,

Congrats and thanks to the team!
Few questions about compile-time DI.

• guice optional dependency

Guice DI support moved to separate module

In Play 2.6, the core Play module no longer includes Guice. You will need to configure the Guice module by adding guice to your libraryDependencies:

libraryDependencies += guice

Is it possible now to run a play app without a runtime dependency injection framework at all and only rely on compile-time DI?

Sorry to ask but it was not obvious reading the documentation above.

• Akka system retrieval

Akka Migration

The deprecated static methods play.libs.Akka.system and play.api.libs.concurrent.Akka.systemwere removed. Please dependency inject an ActorSystem instance for access to the actor system.

For Scala:

class MyComponent @Inject() (system: ActorSystem) {

}

I presume the actour system can be retrieved from the app in the application builder and given as standard constructor parameter to the component? 

If I am not wrong it will be good to add this in the migration method for all the people using compile-time DI.

Thanks,

Mariot

--
You received this message because you are subscribed to the Google Groups "Play Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/CAA%3D11HyXpPPu8SW1zyv7icbJwJjoG17yr9d1HkeMmwAiTaNyzw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way.  Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software.
 
Guardian News & Media Limited is a member of Guardian Media Group plc. Registered Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP.  Registered in England Number 908396


Konstantin Nikiforov

unread,
Feb 21, 2017, 8:14:59 AM2/21/17
to Play framework dev, play-fr...@googlegroups.com
Hi.

Is it possible to use injected QueryStringBindable/PathBindable in router?

For example, *Bindable may depend from Configuration: it transparently produces and verifies signed qs using secret password, specified in injected configuration instance.

четверг, 16 февраля 2017 г., 9:06:57 UTC+3 пользователь Greg Methvin написал:

James Ward

unread,
Feb 21, 2017, 9:40:35 AM2/21/17
to Play framework dev, play-fr...@googlegroups.com
Some feedback from just a few minutes with 2.6:
 - I noticed the Configuration API changes and like the Type Class approach but having yet another API for traversing trees and extracting values seems unnecessary. Can it use the same API as the JSON API?  Also, these API changes aren't mentioned in the Migration Guide.
 - I think the docs should be updated to use Twirl Template injection.  I noticed that https://www.playframework.com/documentation/2.6.x/Migration26#Assets doesn't and I'm sure there are some other places that could benefit from template injection as well.

Thanks for all the hard work!

-James

Will Sargent

unread,
Feb 21, 2017, 12:47:40 PM2/21/17
to Play Framework, play-fram...@googlegroups.com
Hi William,

Thanks for the report.  I've filed https://github.com/playframework/playframework/pull/6992 to make the settings more explicit.  The Akka HTTP server is going to get lots more documentation and features in future milestones.

Thanks,
Will.

On Friday, February 17, 2017 at 8:22:07 AM UTC-8, William Narmontas wrote:
akka-http is not mentioned anywhere in the migration document at: https://www.playframework.com/documentation/2.6.x/Migration26

Where could I read about the rationale of using akka-http?


It caused a breakage for me because in one of my pages I have an (intentionally) long-running future (that does an initial computation for the first page) but with akka-http it returns a 503 after 20 seconds.

Looks like akka-http "request-timeout" setting is 20 seconds by default. A stack overflow question said to set this setting to any value to make it infinite.

However I was not able to set it by going straight to akka-http docs. I went to Play docs and there was no mention of that setting ( https://www.playframework.com/documentation/2.6.x/SettingsAkkaHttp )

Hacking around in AkkaHttpServer class I found this:
val requestTimeoutOption = akkaConfig.getOptional[Duration]("requestTimeout")

I tried setting this setting in application.conf like you would in akka-http. It didn't work on dev/test.
I looked at the implementation of getOptional to find that actually I'd need to do this:
play.server.akka.requestTimeout = null

I tried again, didn't work on dev & test - but did work in prod (I stage'd it).

From this I learned that not all settings from application.conf will be picked up in dev/test.

I tried setting PlayKeys.devSettings += "play.server.akka.requestTimeout" -> null in build.sbt but that didn't seem to work either for whatever reason (doing something wrong? But when I put PlayKeys.devSettings += "play.server.akka.requestTimeout" -> "null" it gave an exception)

Hope this feedback is helpful in improving some things :-)

Will Sargent

unread,
Feb 21, 2017, 1:56:49 PM2/21/17
to Play Framework, play-fram...@googlegroups.com


On Friday, February 17, 2017 at 4:33:02 AM UTC-8, Matthias Kurz wrote:


PlayMinimalJava removes the Java forms / validation library and its dependency on Spring for validation.

I'm not sure whether you'd call it a highlight -- there are no new features or functionality as a result of this change, but it does open the door for other Java based form implementations and could be useful for people looking to minimize the number of dependencies in the Play application.

Will Sargent

unread,
Feb 21, 2017, 2:07:02 PM2/21/17
to Play Framework, play-fram...@googlegroups.com


On Tuesday, February 21, 2017 at 6:40:54 AM UTC-8, James Ward wrote:
Some feedback from just a few minutes with 2.6:
 - I noticed the Configuration API changes and like the Type Class approach but having yet another API for traversing trees and extracting values seems unnecessary. Can it use the same API as the JSON API?  Also, these API changes aren't mentioned in the Migration Guide.
 - I think the docs should be updated to use Twirl Template injection.  I noticed that https://www.playframework.com/documentation/2.6.x/Migration26#Assets doesn't and I'm sure there are some other places that could benefit from template injection as well.

For reference, twirl template injection is https://github.com/playframework/twirl/issues/93  and there's a worked example at https://github.com/playframework/twirl/pull/100#issuecomment-265536917

An example of twirl template injection would be:

public MyController @Inject()(template: views.html.index) extends Controller {
   def index = Action {
      Ok(template())
   }
}

And the reason this is useful is that it means you can inject components directly into the template itself, without having to pass them through the controller:

@this(messagesApi: play.api.i18n.MessagesApi)
@()

@{messagesApi("hello.world")}

The only catch is that you have to declare the following in build.sbt:

TwirlKeys.constructorAnnotations += "@javax.inject.Inject()"

and so it's not quite as transparent and straightforward as it could be.

This could be a highlight, but it's technically Twirl and not Play 2.6 (i.e. you could do this in Play 2.5).  Also, it's not a requirement, and the docs in this case is talking about assets rather than the injection case...

Will.

Will Sargent

unread,
Feb 21, 2017, 2:12:21 PM2/21/17
to Play Framework, play-fram...@googlegroups.com

Is it possible now to run a play app without a runtime dependency injection framework at all and only rely on compile-time DI?

Yes -- it's one of the example projects:


You can also do compile time dependency injection in Java, using Dagger 2 (although it's a proof of concept at this point):


 
Sorry to ask but it was not obvious reading the documentation above.
 
I presume the actour system can be retrieved from the app in the application builder and given as standard constructor parameter to the component? 

Yes.  You can also modify the actor system or swap it out completely:


Thanks,
Will. 

Mike Bryant

unread,
Mar 8, 2017, 11:40:04 AM3/8/17
to Play Framework, play-fram...@googlegroups.com
Great job getting out this first milestone!

I've been trying to update to M1 a 2.5 app with multiple SBT subprojects and am having problems with assets. Whenever my app tries to load an asset it now errors with:

    The application secret has not been set, and we are in prod mode. Your application is not secure.

This is perplexing since a) the secret has been set, and b) it's not in prod mode but either dev or test. However, this error does not happen in prod mode! 

My asset config is still using the 2.5 system, rather than the new one with the paths defined in configuration. The 2.6 subproject documentation does not detail how you deal with assets via configuration if you've got multiple subprojects pulling assets from different paths.

Cheers,
~Mike

Will Sargent

unread,
Mar 8, 2017, 12:35:45 PM3/8/17
to Mike Bryant, Play Framework, play-fram...@googlegroups.com
This may be a product of the global assets setting, where some assets metadata was using the Prod mode internally.  This should be fixed as of PR 6996:


--
Will Sargent
Engineer, Lightbend, Inc.


--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages