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


    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

       With new releases by Android, e.g. Jellybean, it becomes
       imperative for
       us to test this jackrabbit library against each new version of

       Further more, I would also like to emphasize, that there was an
       out of
       memory issue while uploading larger files from Android. So this
       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