Looping in dev :) On Thu, Apr 19, 2012 at 4:08 PM, ashimita <[email protected]> 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 <[email protected]>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 <[email protected] >>> <mailto:[email protected]>**> 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 >> > >
