jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ashimita <ashim...@gmail.com>
Subject Re: Developed jackrabbit-webdav client for Android
Date Thu, 19 Apr 2012 09:43:59 GMT
Hi Julian,

Please find my response embedded. :)

On Thu, Apr 19, 2012 at 12:55 PM, Julian Reschke <julian.reschke@gmx.de>wrote:

> On 2012-04-19 07:56, ashimita wrote:
>
>> Hi Julian,
>>
>> The libraries that are not supported are:
>>
>> org.slf4j.Logger and  org.slf4j.LoggerFactory which are used mainly for
>> logging purpose.
>>
>
> I don't understand. Can't you just add them?
>

      Yes, we can. Right now I have replaced them,
with  java.util.logging.Level and java.util.logging.Logger This effects
almost 15 packages and almost all the classes therein. Are we okay
modifying all of them?

>
>  HttpServletRequest.*getHeader(**)* is also not supported. So here is what
>>
>> the Dalvik VM says, when one uses the getHeader() method in the
>> jackrabbit library:
>>
>> I/*dalvikvm*(368): Could not find method
>>
>> javax.servlet.http.**HttpServletRequest.getHeader, referenced from method
>> org.apache.jackrabbit.webdav.**header.OverwriteHeader.<init>
>>
>
> We're talking about
>
> http://docs.oracle.com/javaee/**6/api/javax/servlet/http/**
> HttpServletRequest.html#**getHeader%28java.lang.String%**29<http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getHeader%28java.lang.String%29>
>
> right?
>
   Yes, that's correct.

>
> Why is it missing, and what is the suggested replacement?
>

    Dalvik virtual machine does not cover all of java APIs. Hence even
though an android application can be compiled with those unsupported API,
at the time of execution (within the Dalvik Virtual machine process space)
they throw exception, as I have pointed out earlier. This
link<http://www.zdnet.com/blog/burnette/java-vs-android-apis/504>talks
about the unsupported APIs.

As of now I was not able to find any replacement other than commenting out
that piece of code. It was not being used to parse any header info for an
Android App.
Instead of using HttpServletRequest, we can try using HttpRequest instead
if we do want to keep that piece of code. I have however not tried the same
with local jar.

>
> (Yes, I'm very confused)
> Sorry, about that. :(
>
>  This was tested against Gingerbread (API 10) and ICS (API 15) using
>> Android emulator. Honeycomb (API 12 and 13) will also not support the
>> same, IMO, since it is between Gingerbread and ICS.
>> I had developed this 1 year back with 2.2.5, and hence relying on meld
>> diff tool to find out the changes. There might be few other APIs as well
>> which may not be supported and which I had taken care of at that time.
>>
>> With new releases by Android, e.g. Jellybean, it becomes imperative for
>> us to test this jackrabbit library against each new version of Android.
>>
>> Further more, I would also like to emphasize, that there was an out of
>> memory issue while uploading larger files from Android. So this feature
>> also needs to be fixed and integrated with the library, now
>> that FileRequestEntity is available with commons-httpclient version 3.1.
>>
>
> Is the OOM issue specific to Android?
>
That's right. Android framework allocates very low memory per process
space. Every Android app, executes in it's own DVM (Dalvik Virtual
Machine). Ideally 24MB is allocated per process space.

>
> As you can guess, I'm confused about the type of changes :-)
>

I hope this time I have clarified. :)

My concern is should we make changes to the otherwise stable codebase only
for Android or should we create a separate folder for it?

>
> Best regards, Julian
>

Mime
View raw message