Play 2.4.0-M3 released!

[James RopR]

Hi all,

I'm pleased to announce the release of Play 2.4.0-M3!  This should be the last milestone before we go into the RC phase, and as with the other milestones, I want to stress that this release is still experimental, there are still things that can and will change between now and the RC phase, particularly in the area of configuration.  Do not upgrade your production application to this release, it's just for experimenting with.

The focus of this milestone has been testing, we've introduced quite a number of new APIs that should allow certain types of testing much easier:

https://www.playframework.com/documentation/2.4.x/ScalaTestingWithGuice

https://www.playframework.com/documentation/2.4.x/ScalaTestingWithDatabases

https://www.playframework.com/documentation/2.4.x/ScalaTestingWebServiceClients

https://www.playframework.com/documentation/2.4.x/JavaTestingWithGuice

https://www.playframework.com/documentation/2.4.x/JavaTestingWithDatabases

https://www.playframework.com/documentation/2.4.x/JavaTestingWebServiceClients

Ben McCann has also done some great work in cleaning up and improving the Java integration test APIs, improving FakeRequest and making Result easier to work with.

Thanks to everyone that has helped with the development of Play 2.4!

Regards,

--

James RopR
Software Engineer

Typesafe – Build reactive apps!
Twitter: @jroper

[Christopher Hunt]

Nice work Play team!

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

[Martin Grotzke]

Awesome, thanks for the milestone!

Cheers,
Martin

--

[Ben McCann]

This is definitely going to be the best Play release yet!  The project is making big strides with each release

--

about.me/benmccann

[Ben McCann]

Thanks for the shout out :-)  Btw, right now I'm working on upstreaming all of Play's improvements to sbteclipse so that there won't be anymore need for PlayEclipse or it will at least be a very minimal few lines

--

about.me/benmccann

[Dominik Dorn]

A related question : Global.java is going away. How is that replaced ? In our case, we need to initialise some Actors. We do roughly ; 

system = ActorSystem.create("messaging");

Camel camel = CamelExtension.get(system);

CamelContext camelContext = camel.context();

ActorRef ref = system.actorOf(....);

in a class called by Global.onStart(). What is the replacement for this ?

I used to do that too. Take a look at the (new?) reactive maps template in activator.. they use the plugin architecture to bootstrap their actors now.. a quite elegant solution, imho. 

Cheers,
Dominik

[Dominik Dorn]

The Plugin architecture is marked deprecated in 2.4.0-M3. I've got that working, but I'm not sure how long that will remain. I would go for a eager singleton, but that also isn't an option.

Afaik the "Plugin architecture" is reborn with just a different name.. I think you can provide plugins now as guice modules or something like that.. 

take a look at this, e.g.

https://github.com/playframework/playframework/blob/master/framework/src/play-jdbc/src/main/scala/play/api/db/DBModule.scala

cheers,

dominik

 

[James RopR]

On 12 Mar 2015 18:04, "Igmar Palsenberg" <ig...@palsenberg.com> wrote:
>
> Hi,

>
>  
>>
>> I'm pleased to announce the release of Play 2.4.0-M3!  This should be the last milestone before we go into the RC phase, and as with the other milestones, I want to stress that this release is still experimental, there are still things that can and will change between now and the RC phase, particularly in the area of configuration.  Do not upgrade your production application to this release, it's just for experimenting with.
>>
>  

> This release has broken the hooks into ApplicationLifecycle.
>
> We do : 
>
> ... extends AbstratModule {
> configure() {
> bind(SomeClass.class).toProvider(SomeClassProvider.class).in(Singleton.class);
> }
>
> @Inject
> SomeClass(ApplicationLifecycle applicationLifecycle) {
>     // Register shutdown hook
> }
>
> This used to work. Now we get a : 
>
> Error injecting constructor, java.lang.IncompatibleClassChangeError: Found interface play.Application, but class was expected
> Any clues on this ?

That's a binary compatibility error, something needs to be recompiled against 2.4.0-M3, either your application, or a library you're depending on.

> A related question : Global.java is going away. How is that replaced ? In our case, we need to initialise some Actors. We do roughly ; 
>
> system = ActorSystem.create("messaging");
> Camel camel = CamelExtension.get(system);
> CamelContext camelContext = camel.context();
>
> ActorRef ref = system.actorOf(....);
>
> in a class called by Global.onStart(). What is the replacement for this ?

Bind a component that depends on ActorSystem as an eager singleton, and create the actors in that components constructor.

>
>
>
> Regards,
>
>
> Igmar
>
> --
> 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.

[Igmar Palsenberg]

 

I'm pleased to announce the release of Play 2.4.0-M3!  This should be the last milestone before we go into the RC phase, and as with the other milestones, I want to stress that this release is still experimental, there are still things that can and will change between now and the RC phase, particularly in the area of configuration.  Do not upgrade your production application to this release, it's just for experimenting with.

The focus of this milestone has been testing, we've introduced quite a number of new APIs that should allow certain types of testing much easier:

https://www.playframework.com/documentation/2.4.x/ScalaTestingWithGuice

https://www.playframework.com/documentation/2.4.x/ScalaTestingWithDatabases

https://www.playframework.com/documentation/2.4.x/ScalaTestingWebServiceClients

https://www.playframework.com/documentation/2.4.x/JavaTestingWithGuice

https://www.playframework.com/documentation/2.4.x/JavaTestingWithDatabases

https://www.playframework.com/documentation/2.4.x/JavaTestingWebServiceClients

It would be very handy if the Application.configuration() object was available before the application is bootstrapped. I need some keys from that in order to properly setup DI bindings, but I can't :

public class CacheModule extends AbstractModule {

      protected void configure() {

              Configuration config = Play.application().configuration().getConfig("");

              // Rest of the DI code

      }

}

This blows up with the infamous "There is no started application" error. This severely limits what can be done with Guice modules. I also can't use a regular Play Module : That doesn't give me access to the Guice Binder, what I need.

Igmar

 

[Rich Dougherty]

On Mon, Mar 16, 2015 at 3:57 AM, Igmar Palsenberg <ig...@palsenberg.com> wrote:

It would be very handy if the Application.configuration() object was available before the application is bootstrapped. I need some keys from that in order to properly setup DI bindings, but I can't :

public class CacheModule extends AbstractModule {

      protected void configure() {

              Configuration config = Play.application().configuration().getConfig("");

              // Rest of the DI code

      }

}

This blows up with the infamous "There is no started application" error. This severely limits what can be done with Guice modules. I also can't use a regular Play Module : That doesn't give me access to the Guice Binder, what I need.

If you can't use Guice modules because need Play-specific stuff and you can't use Play modules because you need Guice-specific stuff, you may need to extend GuiceApplicationLoader, which knows about both. Look at GuiceApplicationLoader and override the load method. You can use your own ApplicationLoader class by setting the "play.application.loader" config setting.

Source is here: https://github.com/playframework/playframework/tree/2.4.0-M3/framework/src/play/src/main/scala/play/api/inject/guice

– Rich

 

--

Rich Dougherty

Engineer, Typesafe, Inc

@richdougherty

[Igmar Palsenberg]

If you can't use Guice modules because need Play-specific stuff and you can't use Play modules because you need Guice-specific stuff, you may need to extend GuiceApplicationLoader, which knows about both. Look at GuiceApplicationLoader and override the load method. You can use your own ApplicationLoader class by setting the "play.application.loader" config setting.

Source is here: https://github.com/playframework/playframework/tree/2.4.0-M3/framework/src/play/src/main/scala/play/api/inject/guice

I was afraid that this was the only solution. I'll work it out, I just have to grasp the Scala code, since it's all kinda new to me, just to better understand what is happening.

Thank !

Igmar 

[James RopR]

On 23 March 2015 at 01:15, James Ward <jlwa...@gmail.com> wrote:

It doesn't look like the Scala 2.10 artifacts were published for this release.

Which ones in particular?

http://search.maven.org/#artifactdetails%7Ccom.typesafe.play%7Cplay_2.10%7C2.4.0-M3%7Cjar

 

--

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.

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

[James Ward]

Ah, I was looking here:

http://repo.typesafe.com/typesafe/releases/com/typesafe/play/play_2.10/

[James Ward]

So the issue I was trying to track down when I ran into this was that the specs2 deps weren't being brought in when depending on:

"com.typesafe.play" %% "play-test" % "2.4.0-M3" % "test"

After looking at the pom.xml the deps are there but they were changed to the "test" scope since M2:

https://github.com/playframework/playframework/commit/ff12063e3265d06beab0b1db7c8bb0ffbf758f5b#diff-9d2a2c65b4e51a5844d4bd269b0b44efR214

Now I'd think that transitive deps in the test scope for test scope dependencies would work just fine.  But apparently not.

Any ideas?

[James RopR]

https://www.playframework.com/documentation/2.4.0-M3/Migration24#Specs-2-support

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

[James Ward]

Thanks! That did the trick. And bravo and further deintertwining the components of Play!

https://www.playframework.com/documentation/2.4.0-M3/Migration24#Specs-2-support

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.

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

[Rich Dougherty]

Hi Johan

We're planning on an RC this week.

Cheers

Rich

On Sat, Apr 11, 2015 at 11:47 AM, Johan Dahlberg <jo...@dahlberg.co> wrote:

Is an RC on the way or will there be more milestones before?

/Johan

--

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.

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

--

[Igmar Palsenberg]

 

I'm pleased to announce the release of Play 2.4.0-M3!  This should be the last milestone before we go into the RC phase, and as with the other milestones, I want to stress that this release is still experimental, there are still things that can and will change between now and the RC phase, particularly in the area of configuration.  Do not upgrade your production application to this release, it's just for experimenting with.

The focus of this milestone has been testing, we've introduced quite a number of new APIs that should allow certain types of testing much easier:

https://www.playframework.com/documentation/2.4.x/ScalaTestingWithGuice

https://www.playframework.com/documentation/2.4.x/ScalaTestingWithDatabases

https://www.playframework.com/documentation/2.4.x/ScalaTestingWebServiceClients

https://www.playframework.com/documentation/2.4.x/JavaTestingWithGuice

https://www.playframework.com/documentation/2.4.x/JavaTestingWithDatabases

https://www.playframework.com/documentation/2.4.x/JavaTestingWebServiceClients

Since about a week, I can't use M3 anymore : 

sbt.ResolveException: unresolved dependency: org.javassist#javassist;3.19.0-GA: configuration not found in org.javassist#javassist;3.19.0-GA: 'compile'. It was required from com.typesafe.play#build-link;2.4.0-M3 compile

Can this be resolved somehow ?

Igmar

 

[James Roper]

It's there:

http://repo1.maven.org/maven2/org/javassist/javassist/3.19.0-GA/javassist-3.19.0-GA.jar

What do your ivy reports say?  See https://www.playframework.com/documentation/2.4.x/SBTDebugging for details on how to access them.

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

--

James Roper
Software Engineer

[Igmar Palsenberg]

 

It's there:

http://repo1.maven.org/maven2/org/javassist/javassist/3.19.0-GA/javassist-3.19.0-GA.jar

What do your ivy reports say?  See https://www.playframework.com/documentation/2.4.x/SBTDebugging for details on how to access them.

Wiping the ivy cache (again) fixed this. While I understand the benefits of SBT, it's error reporting is one of the worst I've ever seen.

Igmar

[Matthias Kurz]

As it seems starting with Play 2.4 the play-enhancer plugin wil handle the Java bytecode enhancements.

Is it somehow possible to disable or not include this plugin? Or is there a settings to skip bytecode enhancement?

Thanks!

[James Roper]

Hi Matthias,

In future, it will be as simple as disablePlugins(PlayEnhancer).  Currently, it's not that simple, instead of using enablePlugins(PlayJava), you can do this:

val myProject = (project in ("."))

  .enablePlugins(Play)
  .settings(play.sbt.PlaySettings.defaultJavaSettings: _*)

  .settings(
    libraryDependencies += javaCore
  )

  

This will give you everything the PlayJava plugin gives you except the PlayEnhancer.

Regards,

James

--

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.

[Matthias Kurz]

Thanks James.
With "in future" you probably mean Play 3 (or maybe Play 2.5)?
Thanks!

[James Roper]

Something like that.

 

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

[Ben McCann]

What's stopping us from being able to disable PlayEnhancer today?

about.me/benmccann

[James Roper]

The Play Java plugin requires it (as in, declares it as a required dependency).  Disable it, sbt will throw an error saying you can't both enable a plugin and disable a plugin it requires.

[Ben McCann]

That's easy to fix, right?  https://github.com/playframework/playframework/pull/4264    Or will this not work...

[Dominik Dorn]

I'm trying to port the spring plugin to play 2.4.0-M3 .. any pointers on what I have to implement / change / disable to make it work? Guice looks like its baked in quite hard (not a plugin anymore), so I'm not sure where to start. 

Would it be "enough" to do it the same way for spring as its in 

https://github.com/playframework/playframework/tree/a0a8bd5796c746334dac1d88f65cda66975cb6a8/framework/src/play-java/src/main/java/play/inject
? 

Is anyone else already working on this? 

Thanks,
Dominik

Dominik Dorn
http://dominikdorn.com | http://twitter.com/domdorn
XING: https://www.xing.com/profile/Dominik_Dorn
LINKEDIN: http://at.linkedin.com/pub/dominik-dorn/66/b42/bb1/

[Ben McCann]

James made an example to work with Play 2.4 and Spring that you should check out
https://github.com/jroper/play-spring

[Dominik Dorn]

Another problem I'm just facing:

When trying to migrate my controllers, I run into problems with the new I18N implicits stuff: 

Code looks like:

Application.scala:

Singleton
class Application @Inject() (
                              userService: UserService,
                              registrationValidators : RegistrationValidators
                              )
  extends Controller with play.api.i18n.I18nSupport {


  def login = LoggedOutAction {
    implicit request =>

      Ok(views.html.logged_out.login())
  }

UserActions.scala:

trait LoggedOutAction extends ActionBuilder[Request]   {
  def invokeBlock[A](req: Request[A], block: Request[A] => Future[Result]): Future[Result] =
    if(UserAuth.isLoggedIn(req)){
      Future(Results.TemporaryRedirect("/logout?url="+req.uri))
    } else {
      block(req)
  }
}

object LoggedOutAction extends LoggedOutAction

I get 
class Application needs to be abstract, since method messagesApi in trait I18nSupport of type => play.api.i18n.MessagesApi is not defined

any clues ? 

Thx,
Dominik

[James Roper]

Hi Dominik,

As Ben pointed out, you really need to start with my PoC for spring support:

https://github.com/jroper/play-spring

We created the Play inject APIs specifically to abstract over providing bindings so that another DI provider, eg spring, can reuse the Play modules defined by each library, and not need to provide their own set of bindings. We intentionally crippled that API so that spring integration could be made to work, eg, it doesn't support binding parameterized types because spring doesn't support autowiring by parameterized types. The spring integration is not easy, spring is not designed to be configured programmatically (no, what spring calls programmatic configuration is not programmatic, it's declarative, annotations etc declare bindings in Java code rather than declaring in xml, there's nothing programmatic about that) and its legacy as an xml based system really shines through (every bean must have a string based id, for example). But it's possible.

My PoC worked for a very old snapshot of play 2.4, and will need to be updated as APIs have since changed. It does not support providing any custom configuration yet.

Regards,

James

[Rich Dougherty]

Hi Igmar

I've pushed a change that lets Guice modules access the Play configuration. This allows you to create dynamic Guice bindings based on config. Here's a Java example:

https://github.com/playframework/playframework/commit/95fe2d116f311a0c89c09deb5f540732dea452b2#diff-94e6b1452077a730cc6a88b817503f54R8

This change is going to be in the next milestone, hopefully the next couple of days.

– Rich

[Igmar Palsenberg]

 

I've pushed a change that lets Guice modules access the Play configuration. This allows you to create dynamic Guice bindings based on config. Here's a Java example:

https://github.com/playframework/playframework/commit/95fe2d116f311a0c89c09deb5f540732dea452b2#diff-94e6b1452077a730cc6a88b817503f54R8

This change is going to be in the next milestone, hopefully the next couple of days.

Great !!! I'll give it a go. I also want to discuss Play's CacheImpl, since it has some serious drawbacks : 

- No way to delete the whole cache

- Implementation interface doesn't really match what EHCache / memcached provides

I've switched to a JSR107 implementation, is this something that can be included within Play ?

Igmar