[2.0.1 Java] is Play 2.0.1 ready for production deployment now?

[Chris B.]

I noticed this unresolved bug:

https://play.lighthouseapp.com/projects/82401/tickets/411-play-20-server-hangs-under-java-7-on-mac-os-x

It seems affecting a number of Linux distributions with the latest Java.

is Play 2.0.1 ready for production deployment now?

[Julien Tournay]

Hi,

Are you deploying on OSX and Java7 ?

Julien

[James Roper]

Depends on what you mean by production ready.  I would have no problems running Play 2.0 on a production system - it works, and all the bugs I've encountered can be worked around (eg, if it doesn't work on Java 7, use Java 6).  But I also have no fears about jumping into the source code and debugging problems and fixing things for myself.

Play 2.0.1 only contained bug fixes, and not all serious bugs were fixed (for example, you still can't set response headers or cookies in an asynchronous response from a promise).  None of the gaping functionality holes were fixed either.

If by production ready, you mean mature, then no, Play 2.0.1 is not mature, and I don't think any of the Play devs would try and argue against that.  If however you mean something that works in a pragmatic sense, then I'd say it's production ready.

[Steven Elliott Jr]

I agree with James - sometimes you're going to have to roll your own for stuff. I just ported a 1.2.4 app to 2.0.1 and it works like a charm. I was lost without SecureSocial and Deadbolt but I hacked some stuff together and it's working just fine.

[Pascal Voitot Dev]

Play2 is a young framework but the engine is production ready, very robust, efficient and heavily scalable. There is still work on tools, modules, helpers etc... But it's on its way, isn't it? ;)

Pascal

On Fri, May 11, 2012 at 5:55 PM, Steven Elliott Jr <srichard...@gmail.com> wrote:

I agree with James - sometimes you're going to have to roll your own for stuff. I just ported a 1.2.4 app to 2.0.1 and it works like a charm. I was lost without SecureSocial and Deadbolt but I hacked some stuff together and it's working just fine.

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

To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

[peter hausel]

Hi James,

On Friday, May 11, 2012 11:50:45 AM UTC-4, James Roper wrote:

Depends on what you mean by production ready.  I would have no problems running Play 2.0 on a production system - it works, and all the bugs I've encountered can be worked around (eg, if it doesn't work on Java 7, use Java 6).  But I also have no fears about jumping into the source code and debugging problems and fixing things for myself.

Could you please put together a simple app that demonstrates the java 7 issue? https://play.lighthouseapp.com/projects/82401/tickets/411-play-20-server-hangs-under-java-7-on-mac-os-x I could not replicate it myself (on os x, using play 2.1-snapshot). 

 None of the gaping functionality holes were fixed either.

Could you please elaborate? 

If by production ready, you mean mature, then no, Play 2.0.1 is not mature, and I don't think any of the Play devs would try and argue against that.  

The framework is young (so in terms of age is by definition "not mature"). Maturity in terms of expectations is highly personal ie lots of folks have specific (and sometimes unrealistic) expectations on what a framework should do for them.

For me it all comes down to whether I can build an app that has predictable runtime characteristics, that provides fast development cycles and cutting edge features, that also has a good eco system and active community(~30 plugins, 5500+ on the mailing list etc.). From my perspective play2 fits the bill. Your mileage may vary.

HTH,

Peter

[James Roper]

Hi Peter,

On Saturday, 12 May 2012 15:30:02 UTC+2, peter hausel wrote:

Hi James,

On Friday, May 11, 2012 11:50:45 AM UTC-4, James Roper wrote:

Could you please put together a simple app that demonstrates the java 7 issue? https://play.lighthouseapp.com/projects/82401/tickets/411-play-20-server-hangs-under-java-7-on-mac-os-x I could not replicate it myself (on os x, using play 2.1-snapshot). 

I wasn't the original one that posted this topic, I was just referring to the original posters issue, I haven't tried anything with Java 7.

 None of the gaping functionality holes were fixed either.

Could you please elaborate? 

The biggest area of functionality holes is in testing, and this has really hurt us on our project, because we've had to choose between ugly work arounds or untested code, which I hate, I feel very uneasy changing code that isn't tested.  The Java FakeRequest class has no way to set any content other than a form body (so if you're like us, and are using Play framework to write a JSON API, you simply can't test it at the controller level without hacks) and also doesn't let you set session data or cookies (unless you handroll the cookie headers), so we can't test our authentication or any controllers that are dependent on having authentication available, because we can't set the current user in the session.

Other things include the WS API in Java doesn't support following redirects, configuring proxies or reading binary responses, and the Promise API in Java is missing the ability to create pure promises (this can be worked around, but became much more inconvenient in Play 2.0.1 because the the Scala Promise.pure() function was changed to accept a function instead of a value).

 

If by production ready, you mean mature, then no, Play 2.0.1 is not mature, and I don't think any of the Play devs would try and argue against that.  

The framework is young (so in terms of age is by definition "not mature"). Maturity in terms of expectations is highly personal ie lots of folks have specific (and sometimes unrealistic) expectations on what a framework should do for them. 

For me it all comes down to whether I can build an app that has predictable runtime characteristics, that provides fast development cycles and cutting edge features, that also has a good eco system and active community(~30 plugins, 5500+ on the mailing list etc.). From my perspective play2 fits the bill. Your mileage may vary.

* Play 2.0.x doesn't have that good IDE support, my Eclipse using colleagues complain to me, and for me on IntelliJ, it still doesn't attach sources of dependent libraries.  I use the gen-idea plugin instead, but the play sources themselves don't get attached, which when documentation is lacking of the framework in general, really hurts.

* Which brings me to another thing, the Play 2 documentation is still lacking - documentation definitely isn't an unrealistic expectation for maturity.  Don't forget that this probably isn't a big issue for you because you already know Play intimately.  It isn't for me anymore either, but I've spent several hours in the Play source code.  For a newbie, it hurts.

* And in reference to the ecosystem, I wrote 3 of those 30 plugins you mentioned, and I'm only doing one project in Play 2.  When I need to write 3 plugins for a framework just to achieve the needs of one project, that says to me that the ecosystem is still lacking, a sign of the immaturity of a framework.

Don't get me wrong, I love play 2, and I love writing plugins for it (it's exciting having the opportunities to get involved at this early stage), but I think it's fair to still call it immature, and I think it's unreasonable to expect it to be anything else.  But it will get there, I'm putting my money on play 2 (figuratively) and investing my time to fix issues, add functionality and fill out the ecosystem, and am thankful for the hard work the dev team does on it.

Cheers,

James

[peter hausel]

Hi James,

Thanks for your comment. Please see my response in-line.

 

The biggest area of functionality holes is in testing, and this has really hurt us on our project, because we've had to choose between ugly work arounds or untested code, which I hate, I feel very uneasy changing code that isn't tested.  The Java FakeRequest class has no way to set any content other than a form body (so if you're like us, and are using Play framework to write a JSON API, you simply can't test it at the controller level without hacks) and also doesn't let you set session data or cookies (unless you handroll the cookie headers), so we can't test our authentication or any controllers that are dependent on having authentication available, because we can't set the current user in the session.

 

It seems like this is mostly fixed in 2.1:

https://github.com/playframework/Play20/blob/master/framework/src/play-test/src/main/java/play/test/FakeRequest.java

 

Other things include the WS API in Java doesn't support following redirects, configuring proxies or reading binary responses, and the Promise API in Java is missing the ability to create pure promises (this can be worked around, but became much more inconvenient in Play 2.0.1 because the the Scala Promise.pure() function was changed to accept a function instead of a value).

 

Also from 2.1:

https://github.com/playframework/Play20/blob/master/framework/src/play/src/main/java/play/libs/F.java#L120

 

 

If by production ready, you mean mature, then no, Play 2.0.1 is not mature, and I don't think any of the Play devs would try and argue against that.  

The framework is young (so in terms of age is by definition "not mature"). Maturity in terms of expectations is highly personal ie lots of folks have specific (and sometimes unrealistic) expectations on what a framework should do for them. 

For me it all comes down to whether I can build an app that has predictable runtime characteristics, that provides fast development cycles and cutting edge features, that also has a good eco system and active community(~30 plugins, 5500+ on the mailing list etc.). From my perspective play2 fits the bill. Your mileage may vary.

* Play 2.0.x doesn't have that good IDE support, my Eclipse using colleagues complain to me

 

eclipse support was completely rewritten in 2.1 and works much much better than before (both for scala and java projects).

 

, and for me on IntelliJ, it still doesn't attach sources of dependent libraries.  I use the gen-idea plugin instead, but the play sources themselves don't get attached, which when documentation is lacking of the framework in general, really hurts.

play 2.1 is now using sbt-idea under the hood as well with a few play specific addon-s. You can get the sources by executing "idea with-sources" 

https://github.com/playframework/Play20/wiki/IDE . If the core framework sources were not attached while using 2.1-SNAPSHOT, please let me know!

* Which brings me to another thing, the Play 2 documentation is still lacking - documentation definitely isn't an unrealistic expectation for maturity.  Don't forget that this probably isn't a big issue for you because you already know Play intimately.  It isn't for me anymore either, but I've spent several hours in the Play source code.  For a newbie, it hurts.

Any specific area you think it's missing? Can you please help us?

 

* And in reference to the ecosystem, I wrote 3 of those 30 plugins you mentioned, and I'm only doing one project in Play 2.

 

Yeah, I like your plugins - good job!

 

 When I need to write 3 plugins for a framework just to achieve the needs of one project, that says to me that the ecosystem is still lacking, a sign of the immaturity of a framework.

With all due respect I disagree with that sentiment and that just underscores what I said about specific expectations. Let's say I write a scala play app without an IDE, while using Postgres or redis - in that case I would not experience any of the shortcomings you mentioned. 

Furthermore, please show me a framework that comes with the plugins you wrote ie. Snapshotting, statsd and mongo jackson support. All those are functionalities that do not belong to the core framework and very specific to your needs. 

 

Don't get me wrong, I love play 2, and I love writing plugins for it (it's exciting having the opportunities to get involved at this early stage), but I think it's fair to still call it immature, and I think it's unreasonable to expect it to be anything else.  But it will get there, I'm putting my money on play 2 (figuratively) and investing my time to fix issues, add functionality and fill out the ecosystem, and am thankful for the hard work the dev team does on it.

Please do not get me wrong, I do value your feedback and as stated above most of the issues you mentioned are valid and addressed in 2.1 already. My main point is that expectations and must-have features are widely differ from project to project. A webframework is only trying to address the most common use cases. 

As I usually say: an important thing to keep in mind is that one person's must-have feature is another person's bloat. Play2 was partly born to allow users to customize the framework for their needs (via plugins plus via framework and build tool level hooks), so for me the fact we already have 30 plugins shows that the concept is indeed working.

Anyway, thank you for your contribution so far and let's try to make play even better together!

Cheers,

Peter