Play plugin dependency management

[Yevgeniy Brikman]

At LinkedIn, we've made heavy use of Play's plugins API: that is, classes that extend play.api.Plugin and are added to an app by putting them into conf/play.plugins. Some of the benefits we've seen:

1. An easy way to tie into Play's lifecycle (onStart/onStop)
2. Users can easily pick and choose which plugins they want
3. Easy to replace a plugin at test time using FakeApplication
4. Easy to override parts of existing functionality (including functionality built into Play itself, such as DBPlugin and MessagesPlugin) by including a subclass of the original plugin in play.plugins.
   

Unfortunately, we haven't found a clean way to manage dependencies between or within plugins. We have plugins that depend on other plugins, sometimes even a lifecycle dependency (e.g. one must start before the other), and there is no way to know this until you get a runtime error and have to figure out that something must be added in just the right spot in conf/play.plugins.

One proposal for consideration: add a instantiatePlugins method to GlobalSettings:

def instantiatePlugins(app: Application): Seq[Plugin]

The default implementation in GlobalSettings would instantiate the default set of plugins that are built into Play (e.g. MessagesPlugin, AkkaPlugin, etc). However, any app could override this method and instantiate their own plugins, taking advantage of the type system to enforce dependencies:

def instantiatePlugins(app: Application): Seq[Plugin] = {

val customPlugin1 = new CustomPlugin1(app)

val customPlugin2 = new CustomPlugin2(app, customPlugin1) 

super.instantiatePlugins(app) ++ Seq(customPlugin1, customPlugin2)

} 

 

This approach would have all the advantages of the original implementation - Play would call onStart/onStop at the right time, it's easy to pick the plugins you want in your own app, override the Global's behavior at test time, and override parts of a plugin - while also making dependency management much easier.

Thoughts?

Jim

[James Roper]

Hi Jim,

Have you seen this pull request?

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

I think it provides what you want, plus more (such as the ability to use DI with plugins, and tie that into Play's DI support for controllers).

Out of the box everything still works the same way, but any part of the current plugin framework can be replaced, including plugin location, plugin instantiation, etc.

We're sitting on it because we're not 100% sure about what the future requirements for Play are, but if you think this will be good, then perhaps we might revisit this PR again.

Cheers,

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/groups/opt_out.

--

James Roper
Software Engineer

Typesafe – Build reactive apps!
Twitter: @jroper

[Yevgeniy Brikman]

Hi James,

No, I hadn't seen that - thanks for the pointer. I have to look more closely at the specific implementation in that pull request, but I really like the general idea. The combination of a simple "getInstance" interface used for all controllers and plugins seems like an excellent way to make Play apps extremely modular and flexible; combined with easy access to Play's default injection mechanism seems like this would be a nice win. I also wonder if this design would allow Play to get away from the stateful singletons, such as play.api.Play, making testing/mocking/etc far easier. 

Did you guys have any concerns about an approach of this sort? 

Jim

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/groups/opt_out.

[James Roper]

Hi Jim,

Getting away from stateful singletons is desirable, and at the moment we do our best to ensure that we don't introduce any new stateful singletons, and that new features are implemented in such a way that they aren't tied to stateful singletons (as much as possible).  But getting rid of them altogether is not in our current priorities.  We think they're needed to provide the Play experience to Java developers.

As for Scala, I see a lot of disagreement in the community about DI, what's the best way to implement it, whether a third party tool is needed etc.  I don't think the jury's out yet on the best way to do DI in Scala, and I'm not talking about what tech should be used (eg guice vs spring), rather which architectural pattern should be used, reflection based (like traditional java DI), cake pattern, monadic composition, implicit parameters etc.  What we go with here could greatly impact what a Play apps look like.

We have talked about attaching the application to a request, and using implicit conversions to make it implicitly available.  That's certainly compatible with Play's current approaches, and can probably be done with a fairly high level of source compatibility, but I'm not sure if passing such a heavy weight god object around like that is a good design, and the number of implicits and implicit conversions being passed around is going to be quite high, making everything a little too magic.

With a few tweaks to the way the router is generated, it would certainly be possible to make Play use the cake pattern for everything.  But cake pattern is very heavy weight, as far as the impact it has on your code is concerned, and is a very opinionated approach.  It also does not lend itself to fast compile times.

And then there's the reflection DI approaches, but these will make us rethink the whole way we do things like actions, consider the following:

def logout = Action { req =>

   Ok.withNewSession

}

How much global state does the above use?  Before the action has even been invoked, during routing actually, a lookup has been done by the ActionBuilder to get the default body parser, and in getting that, it has looked up the maximum body length from the configuration.  Then Ok.withNewSession looks up 7 different config items, including session cookie name, application context, domain, path, max age, secure, http only, all of these coming from Play.current.  If we were to actually put something in the session, it would also look up the application secret from global state to sign it.

What would this look like if we were using DI?  I don't know, maybe we'd need a result builder that could be injected to create results from.  Maybe each time you instantiated an action, you'd need to pass in a BodyParserProvider that knows the config for the body parsers... next thing you know, people are making the same long classname jokes about Play as they do for Spring.  You can see this stuff isn't straight forward.

Anyway, that's a dump of my thoughts.

Cheers,

James

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/groups/opt_out.

[Yevgeniy Brikman]

Hey James,

But getting rid of them altogether is not in our current priorities. We think they're needed to provide the Play experience to Java developers.

Sorry, didn't mean to muddy the waters with the stateful singleton question, as it's a somewhat tangental discussion to injecting controllers/plugins. That said, why are stateful singletons specifically needed by Java developers?

As for Scala, I see a lot of disagreement in the community about DI, what's the best way to implement it, whether a third party tool is needed etc.

Yea, we've definitely run into this too. We have quite a few Play/Scala apps and have not come to a consensus about the best way to go about DI. We've tried cake, implicits, reflection, trait-based, constructor-based, plugin based, and others.

I'm not sure if Play can be agnostic to DI. Play must have some way getting dependencies and will probably need to pick one of the approaches above; in reality, it already has, with reflection-based injection via getControllerInstance and conf/play.plugins. I think the pull request you mentioned above is just a cleaner model for the reflection-based injection. 

Moreover, I suspect that if Play intends to support both Java and Scala, the only DI approach that will work for both is something along the lines of reflection. Cake, implicits, reader monad, etc obviously don't work with Java. I suppose the Java and Scala APIs could be different in how they handle injection too, but is there a way to do that without making the rift between Play/Java and Play/Scala massive?

[..] You can see this stuff isn't straight forward.

No argument :)

That said, the current situation - a mix of singletons and reflection based injection - is not ideal. I would guess that a somewhat opinionated DI approach, even if imperfect, would likely be better than the current in-between state. I'm definitely open to other ideas and proposals, though the pull request above does have the advantages of a) already coded, b) backwards compatible, c) fairly flexible and effective.

Jim

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

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

--

James Roper
Software Engineer

Typesafe – Build reactive apps!
Twitter: @jroper

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Julien Richard-Foy]

Hi,

The fact that we have no control on the Play application “main” entry point leads to the creation of hooks like the one in the PR you pointed to. But to me, these hooks, allowing us to do dependency injection for controllers and soon for plugins, are more a workaround than a real solution. I wish I could control my application instantiation (write the “main”) and wire my dependencies in my preferred way without any need for Play to be aware of my DI mechanism.

What are the things that prevent me to do this? I think the only problem is that the router generates a static call to each HTTP end point. Is there anything else?

Regards,

Julien

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

[Manuel Bernhardt]

Hi,

very nice discussion, I'd like to add a few points.

We've been through the same kind of woes in regards to plugin
dependencies as Jim pointed out, and having a means to control how
plugins get called into life definitely would be a very nice
capability to have. Additionally, I really like the approach of
encapsulating all the "dependency stuff" in one place, allowing to
eventually come up with generic adapters for at least some of the
dependency injection methods available today, making it easier for
Java & Spring folks to migrate over and hence ease adoption.

From my point of view, I don't necessarily feel the urge to have
complete control as to how the Play Application gets wired. After all
Play is a framework, it frames your work :)

In comparison with Play 1.x which has a lot of extension mechanisms
built-in, Play 2.x is already a lot less restrictive as to how things
work. I do sometimes find myself missing some of the "base
infrastructure", such as for example plugin communication - I ended up
extending the base Play plugin and add plugin message broadcasting. As
well as per-plugin root Akka actors.

I'd also tend to say that reflection-based DI is ok - I definitely
would prefer it in favour of the heavy-weight cake pattern. Of course,
reflection-based DI has some drawbacks. Sometimes I find myself in a
situation where I've forgotten to wire a particular type of
controller, and the default behaviour being to delegate to the
object-based access to controllers, things blow up at runtime. I've
played with the idea of writing a macro helper to help avoid this kind
of situation.

Regarding Application: despite of having to remember to import
play.api.Play.current here and there, I find that design to be less
obtrusive than having an Application hang around everywhere. I mean,
it's not like you need it everywhere, I find that it is required in
some locations that deal with configuration, but those can be hidden
away in a base controller, base model, or other inherited locations.

Cheers,

Manuel

[Julien Richard-Foy]

On Wed, Nov 6, 2013 at 12:21 PM, Manuel Bernhardt <bernhard...@gmail.com> wrote:

Regarding Application: despite of having to remember to import
play.api.Play.current here and there, I find that design to be less
obtrusive than having an Application hang around everywhere. I mean,
it's not like you need it everywhere, I find that it is required in
some locations that deal with configuration, but those can be hidden
away in a base controller, base model, or other inherited locations.

Note that if the control were inverted (your code calls Play instead of Play calling your code) as I suggested, you wouldn’t even need this Application parameter in this situation…

The current design makes it pointless to pull some modules out of Play core: for instance the WS module still rely on a Play Application just for configuration purposes though it could be perfectly reusable without a Play application.

[Manuel Bernhardt]

Hi,

On Wed, Nov 6, 2013 at 1:38 PM, Julien Richard-Foy <j...@zengularity.com> wrote:
> Note that if the control were inverted (your code calls Play instead of Play
> calling your code) as I suggested, you wouldn’t even need this Application
> parameter in this situation…

I think it is difficult to address this particular case of inversion
of control, because some kind of uniform contract needs to exist
across the framework on top of which can be built. Now this contract
is called "Application" and provides all sorts of things to
components, both internal and external to the framework (i.e. both in
framework code and in client code).

I mean, arguably, the contract is a bit vague, as it resembles more a
collection of concrete "container" facts (path, classloader, plugins,
routes, ...) and of utility method (getFile, resource, ...), but I
would argue that there needs to be some kind of context in order to
bootstrap the framework.

Would such as an application context, if it can be reduced a little,
be sufficient to satisfy the "we call Play with the following
context"? The trouble of having to pass it all around the place still
remains though, as James described it.

Out of curiosity, how was / is play-mini working?

> The current design makes it pointless to pull some modules out of Play core:
> for instance the WS module still rely on a Play Application just for
> configuration purposes though it could be perfectly reusable without a Play
> application.

Wasn't that a first shot at separating the WS module out? Correct me
if I'm wrong, but the contract of the module to the external world, if
it is only about knowing about a few configuration facts, could be
easily formulated as a trait, thus making it simpler to integrate in a
Play-agnostic environment.

Manuel

[Rich Dougherty]

On Wed, Nov 6, 2013 at 8:44 PM, Yevgeniy Brikman <brik...@gmail.com> wrote:

But getting rid of them altogether is not in our current priorities. We think they're needed to provide the Play experience to Java developers.

Sorry, didn't mean to muddy the waters with the stateful singleton question, as it's a somewhat tangental discussion to injecting controllers/plugins. That said, why are stateful singletons specifically needed by Java developers?

Yes, the "singleton problem" is a big discussion on its own!

I guess James is saying that singletons can be kind of nice when you're first getting started with Play because they're so easy to use (although I'm also not sure why Java is different from Scala in this regard). But I think we all agree that singletons are inflexible and can cause a lot of problems once you try to do anything a bit more complicated. We run into problems quite regularly in the core of Play due to heavy use of singletons and lazy vals, but we're at least trying to slowly improve things where we can. :)

Cheers

Rich

 

--

Rich Dougherty - @richdougherty
Typesafe - Reactive apps on the JVM

[James Roper]

On Wed, Nov 6, 2013 at 6:44 PM, Yevgeniy Brikman <brik...@gmail.com> wrote:

Hey James,

But getting rid of them altogether is not in our current priorities. We think they're needed to provide the Play experience to Java developers.

Sorry, didn't mean to muddy the waters with the stateful singleton question, as it's a somewhat tangental discussion to injecting controllers/plugins. That said, why are stateful singletons specifically needed by Java developers?

Well, not strictly needed, we've all written singleton less Java apps.  But they do open up a lot of possibilities for rapid application development with minimal boiler plate that are a whole lot harder to solve without singletons.

Strictly speaking, thread locals are singletons, for example, and any code that relies on them makes testing difficult because they need to be setup first.

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/groups/opt_out.

[Yevgeniy Brikman]

That's a pretty interesting thought. Could you sketch up a rough idea of what a "hello world" Play app would look like with something like this, perhaps as a github gist? 

Jim

[Yevgeniy Brikman]

Ugh, don't even get me started on ThreadLocal. I'll start a totally separate discussion for that :)

That said, how do we move this discussion forward? I've seen only a few concrete ideas so far:

1. Stick with the current system, which is a mix of stateful singletons and reflection based DI for controllers and plugins.
2. The pull request https://github.com/playframework/playframework/pull/1433 , which offers a slightly nicer version of reflection based DI for controllers and plugins.
3. The roll-your-own-main method mentioned by Julien. I can't help but think how the node.js hello world example is ~7 lines of code and gives you full control over most aspects of the framework. I'd be curious if something similar could be done for Play.

Are there other proposals? And once we have them all on the table, how do you guys go about picking between them?

Jim

[Pascal Voitot Dev]

Yes I confirm, this idea of reversing Play mechanism is very appealing for many reasons and a simili-sample would help bringing the discussion further!

Pascal

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

[Guillaume Bort]

At least for the core & Scala API I think we could remove any direct access to the Application singleton, and replace it everywhere by an (implicit app: Application). 

This application would have been first injected into the stack along with the RequestHeader (or in Global.onStart for processes that are not directly related to any HTTP request).

This would allow to completely remove the need to have the global Application singleton. For backward compatibility we could have an optional Plugin setting up a global singleton during Global.onStart, and a static function allowing to inject it into any scope (the Play.current equivalent).

For Java I don't think there anything better than global singleton (I agree with James then ThreadLocal singletons are global anyway).

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/groups/opt_out.

--

Guillaume Bort, @guillaumebort – http://guillaume.bort.fr

[Julien Richard-Foy]

Here is a gist illustrating my thoughts: https://gist.github.com/julienrf/7352749

That would involve a lot of changes in the way we write Play applications.

[James Roper]

On Thu, Nov 7, 2013 at 9:17 PM, Yevgeniy Brikman <brik...@gmail.com> wrote:

Ugh, don't even get me started on ThreadLocal. I'll start a totally separate discussion for that :)

That said, how do we move this discussion forward? I've seen only a few concrete ideas so far:

1. Stick with the current system, which is a mix of stateful singletons and reflection based DI for controllers and plugins.
2. The pull request https://github.com/playframework/playframework/pull/1433 , which offers a slightly nicer version of reflection based DI for controllers and plugins.
3. The roll-your-own-main method mentioned by Julien. I can't help but think how the node.js hello world example is ~7 lines of code and gives you full control over most aspects of the framework. I'd be curious if something similar could be done for Play.

Technically there's nothing stopping that today - if minimising lines of code for hello world is the a priority ;)  Although we don't have anything out of the box that does this, it would not be hard to write say "play micro", which would allow you to do this:

import play.micro._

PlayApp {

  case (GET, "/foo") => Action {

    Ok("Hello world")

  }

}.start(9000)

Have a look at the Play integration tests, that's pretty similar to what each integration test looks like, it's not hard to do, and the end result is 6 lines of code ;)

 

Are there other proposals? And once we have them all on the table, how do you guys go about picking between them?

The biggest issue from Typesafe's perspective at the moment is that we want to focus on two things for Play 2.3, one being greatly improved client tech tooling, the other being the Java and in particular Java 8 experience.  If we do go about getting rid of global state, we need to do it very carefully, put a lot of thought into it, iterate over a few prototypes.  We're likely to break things, so if we're going to break things, we want to make sure we get it right.  For us, we simply don't have the resources to provide that level of commitment to it.  I think Play 2.4 would be a much more reasonable timeframe to look at it, this is also when we're going to implement a spray backend, which I think fits well with addressing global state.

 

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/groups/opt_out.

[James Ward]

On 11/07/2013 04:03 AM, James Roper wrote:
> On Thu, Nov 7, 2013 at 9:17 PM, Yevgeniy Brikman <brik...@gmail.com
> <mailto:brik...@gmail.com>> wrote:
>
> Ugh, don't even get me started on ThreadLocal. I'll start a totally
> separate discussion for that :)
>
> That said, how do we move this discussion forward? I've seen only a
> few concrete ideas so far:
>

> 1. Stick with the current system, which is a mix of stateful

> singletons and reflection based DI for controllers and plugins.

> 2. The pull request

> https://github.com/playframework/playframework/pull/1433 , which
> offers a slightly nicer version of reflection based DI for
> controllers and plugins.

> 3. The roll-your-own-main method mentioned by Julien. I can't help

Yeah, we do need to fix the singleton app thing but we will have to wait
for 2.4. As James said our priorities for 2.3 are the client side and
the Java side.

Jim: In the meantime is there an easy way to reduce the pain you are
feeling, like: https://github.com/playframework/playframework/pull/1433

>
> Jim
>
> On Wednesday, November 6, 2013 5:50:29 PM UTC-8,

> implementation in that pull request, but I /really/

> like the general idea. The combination of a simple
> "getInstance" interface used for all controllers and
> plugins seems like an excellent way to make Play
> apps extremely modular and flexible; combined with
> easy access to Play's default injection mechanism
> seems like this would be a nice win. I also wonder
> if this design would allow Play to get away from the
> stateful singletons, such as play.api.Play, making
> testing/mocking/etc far easier.
>
> Did you guys have any concerns about an approach of
> this sort?
>
> Jim
>
>
> On Tuesday, November 5, 2013 8:51:35 PM UTC-8,
> james...@typesafe.com wrote:
>
> Hi Jim,
>
> Have you seen this pull request?
>

> https://github.com/__playframewo____rk/playframework/__pull/1433

> <https://github.com/playframework/playframework/pull/1433>
>
> I think it provides what you want, plus more
> (such as the ability to use DI with plugins, and
> tie that into Play's DI support for controllers).
>
> Out of the box everything still works the same
> way, but any part of the current plugin
> framework can be replaced, including plugin
> location, plugin instantiation, etc.
>
> We're sitting on it because we're not 100% sure
> about what the future requirements for Play are,
> but if you think this will be good, then perhaps
> we might revisit this PR again.
>
> Cheers,
>
> James
>
>
> On Wed, Nov 6, 2013 at 3:43 PM, Yevgeniy Brikman
> <brik...@gmail.com> wrote:
>
> At LinkedIn, we've made heavy use of Play's
> plugins API: that is, classes that extend
> play.api.Plugin and are added to an app by
> putting them into conf/play.plugins. Some of
> the benefits we've seen:
>

> 1. An easy way to tie into Play's lifecycle
> (onStart/onStop)
> 2. Users can easily pick and choose which
> plugins they want
> 3. Easy to replace a plugin at test time
> using FakeApplication
> 4. Easy to override parts of existing

> play-framework-dev...@googlegroups.com.
> For more options, visit
> https://groups.google.com/__grou____ps/opt_out
> <https://groups.google.com/groups/opt_out>.
>
>
>
>
> --
> *James Roper*
> /Software Engineer/
> /
> /
> Typesafe <http://typesafe.com/> � Build reactive
> apps!
> Twitter: @jroper <https://twitter.com/jroper>

>
> --
> 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-de...@googlegroups.com.
> For more options, visit
> https://groups.google.com/__grou__ps/opt_out
> <https://groups.google.com/groups/opt_out>.
>
>
>
>
> --
> *James Roper*
> /Software Engineer/
> /
> /
> Typesafe <http://typesafe.com/> � Build reactive apps!
> Twitter: @jroper <https://twitter.com/jroper>

>
> --
> 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-d...@googlegroups.com.
> For more options, visit
> https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.
>
>
>
>
> --
> *James Roper*
> /Software Engineer/
> /
> /
> Typesafe <http://typesafe.com/> � Build reactive apps!
> Twitter: @jroper <https://twitter.com/jroper>

>
> --
> 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
> <mailto:play-framework-dev%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> --

> *James Roper*
> /Software Engineer/
> /
> /
> Typesafe <http://typesafe.com/> � Build reactive apps!
> Twitter: @jroper <https://twitter.com/jroper>

[Yann Simon]

2013/11/7 James Roper <james...@typesafe.com>

On Thu, Nov 7, 2013 at 9:17 PM, Yevgeniy Brikman <brik...@gmail.com> wrote:

Ugh, don't even get me started on ThreadLocal. I'll start a totally separate discussion for that :)

That said, how do we move this discussion forward? I've seen only a few concrete ideas so far:

1. Stick with the current system, which is a mix of stateful singletons and reflection based DI for controllers and plugins.
2. The pull request https://github.com/playframework/playframework/pull/1433 , which offers a slightly nicer version of reflection based DI for controllers and plugins.
3. The roll-your-own-main method mentioned by Julien. I can't help but think how the node.js hello world example is ~7 lines of code and gives you full control over most aspects of the framework. I'd be curious if something similar could be done for Play.

Technically there's nothing stopping that today - if minimising lines of code for hello world is the a priority ;)  Although we don't have anything out of the box that does this, it would not be hard to write say "play micro", which would allow you to do this:

import play.micro._

PlayApp {

  case (GET, "/foo") => Action {

    Ok("Hello world")

  }

}.start(9000)

And could we do that?

import play.micro._

PlayApp {

  case (GET, "/foo") => Action {

    Ok("Hello world")

  }

}.start(9000)

PlayApp {

  case (GET, "/can") => Action {

    Ok("bye bye")

  }

}.start(9001)

 

It would be helpful to start an application using the web client and to mock all its dependencies.

Yann

[Yevgeniy Brikman]

I think this is pretty awesome. 

Perhaps the "default" would still behave the same way as Play apps do today; possibly even setting up the same singletons. However, the "new" way of doing it would be a few lines of code to instantiate things they way you want to and avoid singletons entirely. Since you could easily inject the Application object into your controller/plugins/etc, I think it would work for both Java and Scala.

Jim

--

Guillaume Bort, @guillaumebort – http://guillaume.bort.fr

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.

[Yevgeniy Brikman]

What is the timeline on Play 2.3 and 2.4?

Jim

>                             play-framework-dev+__unsubscribe____@googlegroups.com.

>                             For more options, visit
>                             https://groups.google.com/__grou____ps/opt_out
>                             <https://groups.google.com/groups/opt_out>.
>
>
>
>
>                         --
>                         *James Roper*
>                         /Software Engineer/
>                         /
>                         /
>                         Typesafe <http://typesafe.com/> � Build reactive
>                         apps!
>                         Twitter: @jroper <https://twitter.com/jroper>
>
>                     --
>                     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+__unsubs...@googlegroups.com.

>                     For more options, visit
>                     https://groups.google.com/__grou__ps/opt_out
>                     <https://groups.google.com/groups/opt_out>.
>
>
>
>
>                 --
>                 *James Roper*
>                 /Software Engineer/
>                 /
>                 /
>                 Typesafe <http://typesafe.com/> � Build reactive apps!
>                 Twitter: @jroper <https://twitter.com/jroper>
>
>             --
>             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.

>             For more options, visit
>             https://groups.google.com/__groups/opt_out
>             <https://groups.google.com/groups/opt_out>.
>
>
>
>
>         --
>         *James Roper*
>         /Software Engineer/
>         /
>         /
>         Typesafe <http://typesafe.com/> � Build reactive apps!
>         Twitter: @jroper <https://twitter.com/jroper>
>
>     --
>     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

>     <mailto:play-framework-dev%2Bunsu...@googlegroups.com>.
>     For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> --
> *James Roper*
> /Software Engineer/
> /
> /
> Typesafe <http://typesafe.com/> � Build reactive apps!
> Twitter: @jroper <https://twitter.com/jroper>
>
> --
> 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.

[James Roper]

Hi Jim,

We haven't set a timeframe yet, but I'd expect around February for 2.3, and August for 2.4.  But I just pulled these dates out of the air.

Cheers,

James

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/groups/opt_out.

--

James Roper
Software Engineer

Typesafe – Build reactive apps!
Twitter: @jroper