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 10:39:00 GMT
Looping in dev :)

On Thu, Apr 19, 2012 at 4:08 PM, ashimita <ashimita@gmail.com> wrote:

> *>No, I don't think so. There's a good reason why slf4j is used.*
> I understand that org.slf4j.Logger and  org.slf4j.LoggerFactory may have
> been used for a good reason. I don't know the reason though.
> But if we look at the source code, many places, they are not even used for
> logging. They have just been instantiated in those classes and not used. It
> has been existing from 2.2.5.
> It's like declaring a variable and not using it. Nobody cleared them up as
> well. :)
>
> *> Well, commenting out isn't an option. This needs more research.*
> I agree and well, I have mentioned in my previous email the same thing.
>
> *>Optimally, you don't need Android-specific changes.*
> Android does not support  org.slf4j.Logger or org.slf4j.LoggerFactory. We
> are not ready to replace them for android. So effectively this library will
> not work on Android.
> If we don't need Android-specific changes, wil Jackrabbit-webdav provide a
> solution to work on Android platform now or in the near future? Right now
> it does not.
>
> On Thu, Apr 19, 2012 at 3:49 PM, Julian Reschke <julian.reschke@gmx.de>wrote:
>
>> 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<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<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