Play 2.6.0-M1 released!

[Greg Methvin]

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

Lightbend, Inc.

[Christopher Hunt]

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]

Congratulations Play Team! 

 

Felipe Alfaville

Analista de Sistemas

Contato: (86) 99416-6936

Linkedin: https://br.linkedin.com/in/felipe-alfaville-a786ab51 

[bpo]

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] ::::::::::::::::::::::::::::::::::::::::::::::

[Greg Methvin]

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/

play-omnidoc 2.6.0-M1 has Scala 2.12 support as well: https://oss.sonatype.org/content/repositories/releases/com/typesafe/play/play-omnidoc_2.12/2.6.0-M1/

play-mailer 6.0.0-M1 is also available: https://oss.sonatype.org/content/repositories/releases/com/typesafe/play/play-mailer_2.12/6.0.0-M1/

[ase...@gmail.com]

Hello, 

Is there more information about the choice over akka http over netty? For e.g. if both remain an option why would I choose one over the other especially since the play framework hides alot of the details.

[Vladimir Koshelev]

Hi,

does switching to Akka HTTP as default HTTP server means akka-http is as 

fast as netty now? Are there any benchmarks?

Best regards,

Vladimir

[Vladimir Koshelev]

Hi,

does switching to Akka HTTP as default HTTP server means akka-http is as fast as netty now? Are there any benchmarks?

Best regards,

Vladimir

On Thursday, February 16, 2017 at 7:07:05 AM UTC+1, Greg Methvin wrote:

[Thibault Meyer]

Great news. Is AKKA HTTP is compatible with IPv6 like netty ?

[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

[Matthias Kurz]

Should we mention the new PlayMinimalJava plugin in the release highlights or the migration guide?

https://github.com/playframework/playframework/blob/2.6.0-M1/framework/src/sbt-plugin/src/main/scala/play/sbt/Play.scala#L39

When using the minimal java plugin some dependencies and twirl template imports won't be included:

https://github.com/playframework/playframework/blob/2.6.0-M1/framework/project/Dependencies.scala#L81-L99

https://github.com/playframework/playframework/blob/2.6.0-M1/framework/src/build-link/src/main/java/play/TemplateImports.java#L41-L42

[Christian Schmitt]

> 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

[William Narmontas]

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 :-)

[Mariot Chauvin]

Thanks Christian!

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/6abcbfa2-bf09-4c82-b8c4-aa461ce6f460%40googlegroups.com.

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

[Greg Methvin]

On Fri, Feb 17, 2017 at 6:19 AM, Christian Schmitt <c.sc...@briefdomain.de> wrote:

> 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

We have this project: https://github.com/playframework/play-macwire-di

It's on 2.5.x, but the code should be pretty much the same. We've added some components to BuiltInComponents and the other traits, but nothing major has changed.

 

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/6abcbfa2-bf09-4c82-b8c4-aa461ce6f460%40googlegroups.com.

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

[Konstantin Nikiforov]

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]

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]

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.

[Will Sargent]

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

Should we mention the new PlayMinimalJava plugin in the release highlights or the migration guide?

https://github.com/playframework/playframework/blob/2.6.0-M1/framework/src/sbt-plugin/src/main/scala/play/sbt/Play.scala#L39

When using the minimal java plugin some dependencies and twirl template imports won't be included:

https://github.com/playframework/playframework/blob/2.6.0-M1/framework/project/Dependencies.scala#L81-L99

https://github.com/playframework/playframework/blob/2.6.0-M1/framework/src/build-link/src/main/java/play/TemplateImports.java#L41-L42

For reference, this was https://github.com/playframework/playframework/issues/6221 and was implemented by https://github.com/playframework/playframework/pull/6559

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]

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]

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:

https://github.com/playframework/play-scala-compile-di-with-tests

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

https://github.com/playframework/play-java-dagger2 

 

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:

https://github.com/playframework/playframework/blob/master/framework/src/play/src/main/scala/play/api/libs/concurrent/Akka.scala#L121

Thanks,

Will. 

[Denis Kalinin]

I've just upgraded my sample app to Play 2.6-M1.

It wasn't very difficult, so thanks for your work and a decent migration guide.

However, I have a question. With compile-time DI, I need to add the AssetsComponents trait to the AppComponents class. This trait resides in the 'controllers' package, so it has the same name as the package for my controllers. It's not a generated file, as far as I can tell, but to reference it, I need to use `_root_.controllers.AssetsComponents` (this, by the way, is not obvious from reading the docs as they don't mention the 'root' thing). What is the reason for putting it into this package? Wouldn't it be better to use something more traditional like `play.mvc.controllers`?

[Fabian Köhler]

Is it already planned for this release to remove the TestServer mutexes like this one: https://github.com/playframework/playframework/blob/master/framework/src/play-test/src/main/scala/play/api/test/Helpers.scala#L73 to allow running multiple TestServers at the same time or is this only planned for 3.0 ?

Keep up the good work!

[Greg Methvin]

Hi Denis,

You're right that controllers.AssetsComponents is a little weird. The reason it's in "controllers" is because Assets and other related classes are in the root controllers package, so it made sense that we should keep all that together.

That said, we want to move all the built-in Play controllers to play.controllers. This is planned for 2.6.0 but hasn't been completed yet: https://github.com/playframework/playframework/pull/6555

--

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-framework+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/5e12ee70-29e2-42ec-90b5-2a96dc1b42c2%40googlegroups.com.

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

[Greg Methvin]

Hi Fabian,

I noticed there was not an issue about the test mutexes, so I created one: https://github.com/playframework/playframework/issues/7036

We probably want it to be enabled by default, but we should make it simple to disable the mutex if you're not using global state.

Greg

--
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-framework+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/1a83105e-734e-463c-9e96-43e00e827694%40googlegroups.com.

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

[Dominik Dorn]

The migration guide fails to mention, that the F.Promise class got finally removed.

This might be relevant to people that used to have a "converter" to stepwise migrate their code but didn't finish doing so

or still have references to F.Promise in their code. 

Solution might be to either migrate all the code (which might be quite time consuming - as I just learned), or to copy the F.Promise class into ones own project. We might want to provide this class as a easy download for those people. 

To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/CAA%3D11HzCDhSwP-uwzLjdqAJ4oGRNW9GJ%3DM0Vgn82%3DNVxVCy2Xg%40mail.gmail.com.

[Mike Bryant]

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]

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:

https://github.com/playframework/playframework/pull/6996

--

Will Sargent

Engineer, Lightbend, Inc.

will.s...@lightbend.com

--
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.

[Denis Kalinin]

That's awesome, thanks!

On Monday, March 6, 2017 at 11:59:17 AM UTC+3, Greg Methvin wrote:

Hi Denis,

You're right that controllers.AssetsComponents is a little weird. The reason it's in "controllers" is because Assets and other related classes are in the root controllers package, so it made sense that we should keep all that together.

That said, we want to move all the built-in Play controllers to play.controllers. This is planned for 2.6.0 but hasn't been completed yet: https://github.com/playframework/playframework/pull/6555

On Sun, Mar 5, 2017 at 8:23 AM, Denis Kalinin <denn...@gmail.com> wrote:

I've just upgraded my sample app to Play 2.6-M1.

It wasn't very difficult, so thanks for your work and a decent migration guide.

However, I have a question. With compile-time DI, I need to add the AssetsComponents trait to the AppComponents class. This trait resides in the 'controllers' package, so it has the same name as the package for my controllers. It's not a generated file, as far as I can tell, but to reference it, I need to use `_root_.controllers.AssetsComponents` (this, by the way, is not obvious from reading the docs as they don't mention the 'root' thing). What is the reason for putting it into this package? Wouldn't it be better to use something more traditional like `play.mvc.controllers`?

--

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/5e12ee70-29e2-42ec-90b5-2a96dc1b42c2%40googlegroups.com.

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