--
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.
One thing to note, perhaps obvious, is to import the right WS package: play.modules.gae.WS;
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.
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>
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
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
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
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