jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: Developed jackrabbit-webdav client for Android
Date Thu, 19 Apr 2012 10:19:34 GMT
On 2012-04-19 11:43, ashimita wrote:
> Hi Julian,
>
> Please find my response embedded. :)
>
> On Thu, Apr 19, 2012 at 12:55 PM, Julian Reschke <julian.reschke@gmx.de
> <mailto: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?

No, I don't think so. There's a good reason why slf4j is used.

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

Well, commenting out isn't an option. This needs more research.

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

Optimally, you don't need Android-specific changes.

Best regards, Julian

Mime
View raw message