Anyone tried using async http client on Android?
Tatu Saloranta
java client) on Android, and it fails due to bytecode verification
error, trying to load JDK-based provider (not sure why). Now it may be
that async http client can't run on Android but on off chance that
someone else has tried to run it on (or was planning), I hoped to see
if there are some known gotchas. Specific error is cryptic enough that
it could also be (yet another) bug on Android's VM or class library:
10-19 18:25:13.135: ERROR/AndroidRuntime(287): java.lang.VerifyError:
com.ning.http.client.providers.jdk.JDKAsyncHttpProvider
10-19 18:25:13.135: ERROR/AndroidRuntime(287): at
com.ning.http.client.AsyncHttpClient.loadDefaultProvider(AsyncHttpClient.java:506)
-+ Tatu +-
jfarcand
Can you try:
httpClient = new HttpClient(new JDKAsyncHttpProvider(config));
to see if that make a difference (it shouldn't, but I have a small doubt)
A+
-- Jeanfrancois
>
> -+ Tatu +-
>
Tatu Saloranta
Sure, tried that last night, did not work either. :-)
Some things I did notice, when doing minor troubleshooting:
(a) Looks like async provider also has static dependency on JDK backed
version; this seems unfortunate (it looks like it is linked to allow
using Windows-specific authentication (NTLM?) that only JDK provides,
due to licensing... something apache hc also does not provide).
(b) Fallback to use JDK version is done automatically -- IMO this is
bit dangerous and I would prefer that users would have to explicitly
configure it to be used (but maybe that's just me).
-+ Tatu +-
jfarcand
On 10-10-20 7:59 PM, Tatu Saloranta wrote:
> On Tue, Oct 19, 2010 at 7:43 PM, jfarcand<jfarca...@gmail.com> wrote:
>> Salut,
>>
>> On 10-10-19 9:29 PM, Tatu Saloranta wrote:
>>>
>>> Quick question: I am trying to run a simple app (ning external api
>>> java client) on Android, and it fails due to bytecode verification
>>> error, trying to load JDK-based provider (not sure why). Now it may be
>>> that async http client can't run on Android but on off chance that
>>> someone else has tried to run it on (or was planning), I hoped to see
>>> if there are some known gotchas. Specific error is cryptic enough that
>>> it could also be (yet another) bug on Android's VM or class library:
>>>
>>> 10-19 18:25:13.135: ERROR/AndroidRuntime(287): java.lang.VerifyError:
>>> com.ning.http.client.providers.jdk.JDKAsyncHttpProvider
>>> 10-19 18:25:13.135: ERROR/AndroidRuntime(287): at
>>>
>>> com.ning.http.client.AsyncHttpClient.loadDefaultProvider(AsyncHttpClient.java:506)
>>
>> Can you try:
>>
>> httpClient = new HttpClient(new JDKAsyncHttpProvider(config));
>>
>> to see if that make a difference (it shouldn't, but I have a small doubt)
>
> Sure, tried that last night, did not work either. :-)
>
> Some things I did notice, when doing minor troubleshooting:
>
> (a) Looks like async provider also has static dependency on JDK backed
> version; this seems unfortunate (it looks like it is linked to allow
> using Windows-specific authentication (NTLM?) that only JDK provides,
> due to licensing... something apache hc also does not provide).
Right. I needed support for NTLM :-) But you must pass the JDK's
property to enable it.
I will look at the Android stuff by downloading an emulator. Did you
make any progress in debugging?
> (b) Fallback to use JDK version is done automatically -- IMO this is
> bit dangerous and I would prefer that users would have to explicitly
> configure it to be used (but maybe that's just me).
Agree. I've just cut 1.3.0, but I will add it as a explicit feature on
AsyncHttpProviderConfig.
Thanks!
Tatu Saloranta
>> Some things I did notice, when doing minor troubleshooting:
>>
>> (a) Looks like async provider also has static dependency on JDK backed
>> version; this seems unfortunate (it looks like it is linked to allow
>> using Windows-specific authentication (NTLM?) that only JDK provides,
>> due to licensing... something apache hc also does not provide).
>
> Right. I needed support for NTLM :-) But you must pass the JDK's property to
> enable it.
Yeah I understand need for NTLM... unfortunate but necessary, :)
> I will look at the Android stuff by downloading an emulator. Did you make
> any progress in debugging?
No, I actually ended up implementing a separate wrapper for the client
API, just because we are doing a hackathon demo, to get things
working.
But I can maybe help once this is over.
I wonder if Netty and nio in general are supposed to work on Android or not.
>
>> (b) Fallback to use JDK version is done automatically -- IMO this is
>> bit dangerous and I would prefer that users would have to explicitly
>> configure it to be used (but maybe that's just me).
>
> Agree. I've just cut 1.3.0, but I will add it as a explicit feature on
> AsyncHttpProviderConfig.
That would be nice I think.
-+ Tatu +-