play.libs.WS with GAE

85 views
Skip to first unread message

Tom Carchrae

unread,
Dec 2, 2011, 1:51:37 PM12/2/11
to play-fr...@googlegroups.com
I am curious to know if anyone has had any success (or given up because of failure) using Play's WS lib ( http://www.playframework.org/documentation/api/1.2.4/play%2Flibs%2FWS.html ) with Google AppEngine?

When I tried, it blew up because of a thread lock issue.  This is the same kind of error I've encountered before trying to use Http Client libraries on app engine.  My current solution is some ugly code that uses the java.net package; which I'd love to replace.  

So, my question is:  did you find a way to make play.libs.WS work or if not, what do you use to make API calls from your app to other web services.

Thanks in advance,

Tom


Pascal Voitot Dev

unread,
Dec 2, 2011, 2:19:46 PM12/2/11
to play-fr...@googlegroups.com
Hi,

In play-gae module trunk, I recently committed a WS class written by Erwan Loisant some time ago. Maybe you could try it to see if it's better (I never tried it till now).

Thanks
Pascal



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

Tom Carchrae

unread,
Dec 2, 2011, 9:46:59 PM12/2/11
to play-fr...@googlegroups.com
Thanks Pascal, I gave it a try and it seemed to work on a quick GET test - I used Play 1.2.4 for the test.  (also big thanks to you for update to the gae module)

Tom Carchrae

unread,
Dec 2, 2011, 10:34:40 PM12/2/11
to play-fr...@googlegroups.com
One thing to note, perhaps obvious, is to import the right WS package: play.modules.gae.WS;

Pascal Voitot Dev

unread,
Dec 3, 2011, 5:40:09 AM12/3/11
to play-fr...@googlegroups.com
So it means this WS is useful in GAE :D
With Erwan and DRoch, we were wondering if we could remove it and replace it by classic play.libs.WS. Apparently not :D

If you could add a small paragraph in the doc about that and the import and push it, it would be very nice ;)

Pascal

On Sat, Dec 3, 2011 at 4:34 AM, Tom Carchrae <t...@carchrae.net> wrote:
One thing to note, perhaps obvious, is to import the right WS package: play.modules.gae.WS;

Tom Carchrae

unread,
Dec 3, 2011, 9:34:04 AM12/3/11
to play-fr...@googlegroups.com
I'm afraid so!  :)   It would be nice if there was a way that the GAE WS could just configure the 'classic' one.  

Glad I caught you before you threw it out!  :)  I'll see about updating the doc, and maybe if I have time look at the difference between the two WS versions.

Tom

Pascal Voitot Dev

unread,
Dec 3, 2011, 9:36:41 AM12/3/11
to play-fr...@googlegroups.com
The main difference is the library used to call WS!
GAE has a few restrictions in Java libraries

Thanks for contrib
Pascal

Erwan Loisant

unread,
Dec 3, 2011, 2:20:28 PM12/3/11
to play-fr...@googlegroups.com

In 1.2 the WS has different implementations. The GAE module automatically selected the jdk backend instead of async http client. The reason I made it possible to switch implementation was to work on GAE.

In 2.0 there is only async http client. AHC itself has different backends (default is netty ). We need to see if it works done on gae, otherwise we may want to let the developer change the ahc backend to be used.

Tom Carchrae

unread,
Dec 13, 2011, 8:04:56 AM12/13/11
to play-framework
Perhaps I should have read more carefully between the lines. Erwan is
saying that the WS code Pascal included in the GAE module is not
needed. I've been using it and there were quite a few problems with
it.

Now, I've started using the Play.libs.WS library and it seems to work
fine. I had tried this before in the past and it did not work
correctly for me, throwing violations on GAE. I presume this was
because I had used an old version of Play that did not have this
feature in it.

So, Pascal, please remove play.modules.gae.WS from the gae-module. It
has bugs in it (sets parameters incorrectly, crashes because
connection is already open on certain method calls) and most of all,
because it is not necessary.

Tom

On Dec 3, 11:20 am, Erwan Loisant <elois...@gmail.com> wrote:
> In 1.2 the WS has different implementations. The GAE module automatically
> selected the jdk backend instead of async http client. The reason I made it
> possible to switch implementation was to work on GAE.
>
> In 2.0 there is only async http client. AHC itself has different backends
> (default is netty ). We need to see if it works done on gae, otherwise we
> may want to let the developer change the ahc backend to be used.

> On Dec 3, 2011 3:36 PM, "Pascal Voitot Dev" <pascal.voitot....@gmail.com>

Pascal Voitot Dev

unread,
Dec 13, 2011, 8:07:50 AM12/13/11
to play-fr...@googlegroups.com
Oh great, you tested it!
Please open an issue on github so that I deal with other issues!
It's not good finally so remove it :)

Pascal

Tom Carchrae

unread,
Dec 13, 2011, 8:54:04 AM12/13/11
to play-fr...@googlegroups.com
Issue Opened.

I'll let you know if I come across any other issues; I just started
using the Play one, but it works much better. I had been making fixes
to the other WS code and that seemed wrong.

Also, thanks for publishing the module. It makes it much nicer to
tell the team to install the module the easy way.

Tom

Pascal Voitot Dev

unread,
Dec 13, 2011, 8:56:26 AM12/13/11
to play-fr...@googlegroups.com
The play WS is better anyway so if it works, let's go!

We should think about Tasks and other stuff from GAE!

Pascal

Tom Carchrae

unread,
Dec 13, 2011, 9:03:36 AM12/13/11
to play-fr...@googlegroups.com
> We should think about Tasks and other stuff from GAE!

Oh ho ho.... we'll be making a Model implementation for the Datastore
next! :)

I'd be happy to contribute any extensions I implement, but am really
overloaded so has to be on as needed basis.

The other one I'm interested is the Channel API, and XMPP, and...
well, there are lots of interesting things. :)

Tom

Pascal Voitot Dev

unread,
Dec 13, 2011, 9:08:34 AM12/13/11
to play-fr...@googlegroups.com
I don't use much GAE recently as I'm busy on other projects.
You seem to be quite expert in it ;)

Don't hesitate to contribute!
Anyway, what should be added first IYO? If we had to add a new feature, which one would it be?

pascal

Tom Carchrae

unread,
Dec 13, 2011, 9:20:45 AM12/13/11
to play-fr...@googlegroups.com
On Tue, Dec 13, 2011 at 6:08 AM, Pascal Voitot Dev
<pascal.v...@gmail.com> wrote:
> I don't use much GAE recently as I'm busy on other projects.
> You seem to be quite expert in it ;)

Not so sure about that, but have been using it for a year or so. The
upside of the experience is nearly all other environments are easier
to code in. But none are as easy to deploy. You pay for your cake
somewhere.

> Don't hesitate to contribute!
> Anyway, what should be added first IYO? If we had to add a new feature,
> which one would it be?

Focusing on the core Play functions seems to make sense. So, I agree,
if the Tasks API could be used to support Play Jobs, that would be
useful. But that said, I don't have any pressing need for it at the
moment.

Tom

Pascal Voitot Dev

unread,
Dec 13, 2011, 9:23:16 AM12/13/11
to play-fr...@googlegroups.com

Anyway, I don't have time right now but that's just to write a todo list!
 

Raphael André Bauer

unread,
Jan 6, 2012, 12:45:14 PM1/6/12
to play-fr...@googlegroups.com
On Tue, Dec 13, 2011 at 2:07 PM, Pascal Voitot Dev
<pascal.v...@gmail.com> wrote:
> Oh great, you tested it!
> Please open an issue on github so that I deal with other issues!
> It's not good finally so remove it :)

Just in case anybody is interested...
I can confirm that since 1.2.4 play.libs.WS is working for me, too,


Best,


Raphael

--
inc: http://ars-machina.raphaelbauer.com
tech: http://ars-codia.raphaelbauer.com
web: http://raphaelbauer.com

Tom Carchrae

unread,
Jan 6, 2012, 3:03:42 PM1/6/12
to play-fr...@googlegroups.com
Yes it is good.  But don't try to attach a file to a PUT/POST.  That code is uncommented/unimplemented for the URLFetch version of WS.

Short term fix should be to throw a not-implemented exception.  The commenting out leads to more bug hunting hours and confusion.  I'm not sure if this is yet fixed in the 1.2.x version.

Tom
Reply all
Reply to author
Forward
0 new messages