App engine 1.6
Opened this issue · 16 comments
Please add 1.6 support
I'm working on it right now and should deliver a new draft version for tests quite soon!
Thanks man, you are great.
Will you add cron and task queue support for play?
I'm not sure it's possible because Google has the bad idea in general to write its Java API linked to java servlets which is a really bad idea and even worse when you use Play :D :D
Need some study... if you have information, don't hesitate!
I've just asked the same question to Pascal on Twitter. Wouldn't it be awesome to wrap also those GAE services and make a GAE fully portable (using Siena of course)?
What's exactly the problem with servlets?
I understand Play is not a servlet container but on GAE Play must have been implemented as a servlet, I guess it's a catch all servlet, isn't it?
I don't know how tasks work in Play (I'm new to Play), but to the task engine in GAE I don't think the task has to be a servlet as long as it's an addressable web service.
So if you expose a task with a Play controller at an url "/tasks/worker" then you should be able to enqueue it with a call to:
QueueFactory.getDefaultQueue().add( withUrl( ''/tasks/worker" )
I don't say it's impossible, it just need to be studied a bit :D
actually play-gae is a trick that uses low level GAE Environment and NOT
the classic GAE dev appserver. That's why we don't have the famous /_ah URL.
But after you do "play gae:deploy" yes play is running behind a servlet.
The problem of GAE SDK is that all APIs are build on HttpServletRequest
instead of streams of data plugged on Servlets.
Maybe we need to rethink the play-gae module but it's hard if we want to
keep the marvelous play dev environment!
Pascal
On Fri, Nov 25, 2011 at 12:09 AM, ZiglioNZ <
reply@reply.github.com
wrote:
I've just asked the same question to Pascala on Twitter. Wouldn't it be
awesome to wrap also those GAE services and make a GAE fully portable
(using Siena of course)?What's exactly the problem with servlets?
I understand Play is not a servlet container but on GAE Play must have
been implemented as a servlet, I guess it's a catch all servlet, isn't it?
I don't know how tasks work in Play (I'm new to Play), but to the task
engine in GAE I don't think the task has to be a servlet as long as it's an
adressable web service.
So if you expose a task with a Play controller at an url "/tasks/worker"
then you should be able to enqueue it with a call to:QueueFactory.getDefaultQueue().add( withUrl( ''/tasks/worker" )
Reply to this email directly or view it on GitHub:
#31 (comment)
I've read this thread:
http://groups.google.com/group/play-framework/browse_thread/thread/d09cba547e83999/c5efdf8333055c30?lnk=gst&q=ApiProxy#c5efdf8333055c30
So the problem with deploying it as a war appears to be that play wouldn't run in the same 'playful' way.
I don't understand exactly what they mean when they say 'just hit reload to see the changes'.
When I develop in Eclipse and run from Eclipse, little changes are swapped at runtime without the need to restart.
Is that how Play work?
I don't know anything about com.google.apphosting.api.ApiProxy, first time I see it.
Does this way of running play actually make play applications on GAE run any differently and faster than standard GAE apps?
I don't want to keep Pascal awake all night :-) you may want to have a look at Restlet GAE edition:
http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/252-restlet.html
http://wiki.restlet.org/docs_2.0/13-restlet/28-restlet/81-restlet.html
Update, this is all too interesting:
http://theikester.wordpress.com/2010/05/07/can-the-play-framework-play-nice-with-others/
Well, I guess Play is so radically different that it's difficult but not impossible to use it side by side with servlets.
One solution, deploying locally as a war, means losing the productivity gain from Play's reload cycle.
Maybe there's another way... food for thoughts
I went to bed anyway :D
On Fri, Nov 25, 2011 at 1:11 AM, Emanuele Ziglioli <
reply@reply.github.com
wrote:
I've read this thread:
So the problem with deploying it as a war appears to be that play wouldn't
run in the same 'playful' way.
I don't understand exactly what they mean when they say 'just hit reload
to see the changes'.
When I develop in Eclipse and run from Eclipse, little changes are swapped
at runtime without the need to restart.
Is that how Play work?When in dev mode, play recompiles what it needs to recompile without
redeploying all the stuff. That's why it's so practical and productive also.I don't know anything about com.google.apphosting.api.ApiProxy, first time
I see it.
Does this way of running play actually make play applications on GAE run
any differently and faster than standard GAE apps?ApiProxy is a proxy to the GAE service developed mainly for tests
apparently. But Guillaume used it to plug GAE services on Play and not Play
on GAE dev appserver.
The problem of this approach is that we don't have access to the /_ah URLs
because we aren't in the same servlet container as GAE app server when
developing with Play.
Actually I really find the GAE dev app server uses
HttpServletRequest/Response everywhere instead of using an abstraction of
it which makes it difficult to use GAE APIs outside their SDK.
Anyway, losing Play productivity by generating a WAR to be deployed into
Jetty as GAE AppServer does would be a shame.
So my idea is to study if we can do else.
Adding taskqueues and such services may be possible...
Once deployed in GAE, the Play instance runs behind a servlet so you can
access the servlet info there but not when you are developing.
I think Play provides something much more powerful than the classic WAR
mechanism in development phase and we must keep that!
An advantage of Play is also that it generates light Java servers without
much overhead compared to Spring based (classic Spring or even Grails) and
I don't speak about JEE. Your server is small and runs smoothly with a very
reasonable cold start time.
Pascal
I don't want to keep Pascal awake all night :-) you may want to have a
look at Restlet GAE edition:
http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/252-restlet.html
http://wiki.restlet.org/docs_2.0/13-restlet/28-restlet/81-restlet.htmlI was already sleeping :D
Reply to this email directly or view it on GitHub:
#31 (comment)
I think we just enjoy Play on app engine. Now it is great, just support new versions of gae.
I went to bed anyway :D
I hope you had a good sleep over the week end!When in dev mode, play recompiles what it needs to recompile without
redeploying all the stuff. That's why it's so practical and productive also.
Eclipse does hot code swap for me, most of the time. Having never used an EE container, I struggle to understand the advantage that Play would bring on the development side. Is there anything in particular that Play can do better than Eclipse? How do you debug (if you need to)?ApiProxy is a proxy to the GAE service developed mainly for tests
apparently. But Guillaume used it to plug GAE services on Play and not Play
on GAE dev appserver.
Very clever! But then on production, GAE is still a servlet container so it certainly runs slower than on bear HttpRequest/Response (has anybody measured the impact?). I wonder whether anyone has filed a request to run GAE without servlets... Considering they now provide other runtimes such as go, it should be feasile.
The problem of this approach is that we don't have access to the /_ah URLs
because we aren't in the same servlet container as GAE app server when
developing with Play.
Actually I really find the GAE dev app server uses
HttpServletRequest/Response everywhere instead of using an abstraction of
it which makes it difficult to use GAE APIs outside their SDK.
Now that's a real problem. For example we use the GAE mail service to receive e-mails and that's implemented via servlet, (via web.xml). Does that mean that Play cannot access that service for example?
Perhaps we could register that service via app.yaml also on a Java App:
http://code.google.com/appengine/docs/python/mail/receivingmail.html
If that works, potentially there could be ways to use GAE services without the need for servlets!
That would be mean rewriting any class that implements those services via servlets
Incidentally also Restlet can work natively, without a servlet container.
On Sun, Nov 27, 2011 at 10:42 PM, Emanuele Ziglioli <
reply@reply.github.com
wrote:
I went to bed anyway :D
I hope you had a good sleep over the week end!Not really! weekend with friends... Not enough sleep but great moments with
friends :DWhen in dev mode, play recompiles what it needs to recompile without
redeploying all the stuff. That's why it's so practical and productive
also.
Eclipse does hot code swap for me, most of the time. Having never used an
EE container, I struggle to understand the advantage that Play would bring
on the development side. Is there anything in particular that Play can do
better than Eclipse? How do you debug (if you need to)?Eclipse host swap is very limited compared to Play (and JRebel). As soon as
you change a function name or signature or an XML, you need to redeploy.
With Play, you don't need that. Moreover, it generally updates your DB
model in dev mode automatically so you are really quick and productive!
You debug play by connecting in remote debug mode to Play from Eclipse!
It works perfectly!
I do it from IDEA also and in Scala too :D
ApiProxy is a proxy to the GAE service developed mainly for tests
apparently. But Guillaume used it to plug GAE services on Play and not
Play
on GAE dev appserver.Very clever! But then on production, GAE is still a servlet container so
it certainly runs slower than on bear HttpRequest/Response (has anybody
measured the impact?). I wonder whether anyone has filed a request to run
GAE without servlets... Considering they now provide other runtimes such as
go, it should be feasile.GAE in Java only accepts Servlet container. Basically it's a servlet
container. Anyway play behind a servlet doesn't reduce any performance
because the request headers/body are exactly the same. The only difference
is that Play doesn't care about servlet contexts as it is stateless.
The best thing could be to run a Play server directly within GAE without
packaging it as a WAR as you can do on playapps, heroku or cloudbees...
maybe in the future if Google moves in the right direction ;)The problem of this approach is that we don't have access to the /_ah
URLs
because we aren't in the same servlet container as GAE app server when
developing with Play.
Actually I really find the GAE dev app server uses
HttpServletRequest/Response everywhere instead of using an abstraction of
it which makes it difficult to use GAE APIs outside their SDK.Now that's a real problem. For example we use the GAE mail service to
receive e-mails and that's implemented via servlet, (via web.xml). Does
that mean that Play cannot access that service for example?
Perhaps we could register that service via app.yaml also on a Java App:
http://code.google.com/appengine/docs/python/mail/receivingmail.html
You can call mail service from Play. It works!
If that works, potentially there could be ways to use GAE services without
the need for servlets!
That would be mean rewriting any class that implements those services via
servlets
Incidentally also Restlet can work natively, without a servlet container.
It would be a shame to have to rewrite GAE SDK!
But if Google API were not directly linked to HttpServlet but abstraction
of it, it would help a lot to connect lightweight solutions such as Play.
Play works already very well and is certainly much versatile than other
Java solutions in GAE. Its only drawback for the time being IMO is that the
gae+play dev server lacks a few feature that come with default gae dev
server.
Pascal
Reply to this email directly or view it on GitHub:
#31 (comment)
You can call mail service from Play. It works!
Great, I couldn't find it in the code, where is it?
So there should be a way to use task queues and chron jobs too!
And mapreduce......
On Tue, Nov 29, 2011 at 11:46 AM, Emanuele Ziglioli <
reply@reply.github.com
wrote:
You can call mail service from Play. It works!
Great, I couldn't find it in the code, where is it?
So there should be a way to use task queues and chron jobs too!
And mapreduce......
look in the sample app in play-gae code written by Guillaume, it sends
mails :D
Task queues/Cron is next step... mapreduce I don't know how it works in GAE
yet!
Reply to this email directly or view it on GitHub:
#31 (comment)
It's 'receiving e-mails' that I was trying to understand whether it works with Play-Gae.
MapReduce is very easy to setup (if you've got servlets). It uses tasks and provides a console. But you have to use the datastore api for now: http://techno.emanueleziglioli.it/2011/11/using-mapreduce-to-refactor-entities-on.html
ah receiving emails might be a bit more complicated :D
Don't hesitate to contribute because I'm busy on other projects too and
can't spend too much time on play-gae!
I did this work on play-gae because it was a pity to let play-gae in this
state. But I don't work only on GAE and I use it mainly for small private
projects.
I'll go on adding new features when I have time or consolidate
contributions but don't hesitate to contribute too!
By the way, did you see my GoogleCloudSql tutorial with new play-gae and
new play-siena?
Pascal
On Tue, Nov 29, 2011 at 12:05 PM, Emanuele Ziglioli <
reply@reply.github.com
wrote:
It's 'receiving e-mails' that I was trying to understand whether it works
with Play-Gae.MapReduce is very easy to setup (if you've got servlets). It uses tasks
and provides a console. But you have to use the datastore api for now:
http://techno.emanueleziglioli.it/2011/11/using-mapreduce-to-refactor-entities-on.html
Reply to this email directly or view it on GitHub:
#31 (comment)
By the way, did you see my GoogleCloudSql tutorial with new play-gae and new play-siena?
Not yet, I certainly will! time to turn the damn laptop off, it's already tomorrow :-)
I'd like to try Play, it looks like a good way to make apps portable, since it's a platform. And in that case I'll be happy to contribute.
Am still using Restlet and once I thought I would use it to abstract from GAE and Vosao. I soon realized it was a too hard task. It could be a different story with Play.