Forum: JRuby Getting access to Java callback code for overriding in JRuby

Hi,


I'm trying to build a wrapper around the ning AsyncHttpClient using 
JRuby, to end up with a multi-request http client somewhat like Typhoeus 
(which doesn't run under JRuby from what I can see).

Everything works quite well so far, but I need to be able to get access 
to the client's onCompleted callback in order to inject my desired 
behaviour into it, and I'm not very sure how to do that.

The Java client code looks like this:


    import com.ning.http.client.*;

    import java.util.concurrent.Future;

    AsyncHttpClient asyncHttpClient = new AsyncHttpClient();
    asyncHttpClient.prepareGet("http://www.ning.com/").execute(new 
AsyncCompletionHandler<Response>(){

        @Override
        public Response onCompleted(Response response) throws Exception{
            // Do something with the Response
            // ...
            return response;
        }

        @Override
        public void onThrowable(Throwable t){
            // Something wrong happened.
        }
    });



I can already access most of the functionality I need from the library, 
but what I don't understand is how I would represent this in JRuby:

.execute(new AsyncCompletionHandler<Response>() {
# and everything inside it
});

Is there a suggested way to get access to the public Response 
onCompleted(Response response) throws Exception?

Should I just open the AsyncCompletionHandler class and define my own 
behaviour there? I think it's likely that the behaviour will be the same 
for all object instances.

Dave -

Maybe I'm not understanding, but I'm thinking that the thing to do here
would be to define your own class that implements your own onCompleted
method, and pass an instance of that class to the execute method.  You
could subclass

AsyncCompletionHandler<Response> if you need any of its behavior, and 
then call super where necessary.

- Keith

Keith R. Bennett
http://about.me/keithrbennett

I'm interested in the answers to the rest of your question, but 
regarding
Typhoeus:

On Wed, Nov 21, 2012 at 12:21 PM, Dave Hrycyszyn <
> dave.hrycyszyn@headlondon.com> wrote:

<snip>

I'm trying to build a wrapper around the ning AsyncHttpClient using 
JRuby,
> to end up with a multi-request http client somewhat like Typhoeus (which
> doesn't run under JRuby from what I can see).


Typhoeus does work in JRuby. I believe you have to use the FFI based
version (I think that starts with 0.4). We are currently are using 0.4.2
under JRuby for a couple services.

Thanks for the responses so far, I'm back on this and will try out the 
subclassing approach.

Richie, that's interesting about the FFI interface on Typhoeus - I 
assume it's running a bunch of unmanaged threads outside the JVM then? I 
guess it'd be as stable as it is on MRI.

Hm.



On Nov 21, 2012, at 6:50 PM, Richie Vos wrote:

I'm interested in the answers to the rest of your question, but 
regarding Typhoeus:

On Wed, Nov 21, 2012 at 12:21 PM, Dave Hrycyszyn 
<dave.hrycyszyn@headlondon.com<mailto:dave.hrycyszyn@headlondon.com>> 
wrote:
<snip>
I'm trying to build a wrapper around the ning AsyncHttpClient using 
JRuby, to end up with a multi-request http client somewhat like Typhoeus 
(which doesn't run under JRuby from what I can see).

Typhoeus does work in JRuby. I believe you have to use the FFI based 
version (I think that starts with 0.4). We are currently are using 0.4.2 
under JRuby for a couple services.

On Thu, Nov 22, 2012 at 6:57 AM, Dave Hrycyszyn <
dave.hrycyszyn@headlondon.com> wrote:

> ...
>
Richie, that's interesting about the FFI interface on Typhoeus - I 
assume
> it's running a bunch of unmanaged threads outside the JVM then? I guess
> it'd be as stable as it is on MRI.
>

Typhoeus just farms request handling out to libcurl. I'm not intimately
familiar with how libcurl's multi support works (
http://curl.haxx.se/libcurl/c/libcurl-multi.html), but I don't think it
actually uses threads. Someone on the Typhoeus group
https://groups.google.com/forum/?fromgroups#!forum/typhoeus could likely
give a more concrete answer though.