[logback-user] use of java.io.File in logback / Android

[Robert Schmid]

OK, I found my pitfalls.

First, the Android VM is a not really a Java VM, it is a proprietary VM that translates java into its own bytecode.  I don't know why they felt this was necessary but it is certainly annoying.

Second, the Android implementation of the JDK is missing quite a few standard packages like javax.naming, java.lang.management and, of course, javaee classes.  So I tried to build an android version of logback in using the android compiler and adding in java framework jars like jndi.jar, jaf.jar,javamail.jar, etc.

What I got for this was the following compiler message;

Attempt to include a core class (java.* or javax.*) in something other
than a core library. It is likely that you have attempted to include
in an application the core library (or a part thereof) from a desktop
virtual machine. This will most assuredly not work. At a minimum, it
jeopardizes the compatibility of your app with future versions of the
platform. It is also often of questionable legality.

If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine distribution,
as opposed to compiling an application -- then use the
"--core-library" option to suppress this error message.

If you go ahead and use "--core-library" but are in fact building an
application, then be forewarned that your application will still fail
to build or run, at some point. Please be prepared for angry customers
who find, for example, that your application ceases to function once
they upgrade their operating system. You will be to blame for this
problem.

If you are legitimately using some code that happens to be in a core
package, then the easiest safe alternative you have is to repackage
that code. That is, move the classes in question into your own package
namespace. This means that they will never be in conflict with core
system classes. If you find that you cannot do this, then that is an
indication that the path you are on will ultimately lead to pain,
suffering, grief, and lamentation.

This strikes me as good advice.  I don't really have the time to hunt down the source code for all those packages and add them under special package structures so, instead, I started removing classes.

I was able to get logback classic to compile in android by removing these classes and packages;

ch.qos.logback.classic.
boolex.GEventEvaluator.java
boolex.JaninoEventEvaluator.java
gaffer.GafferUtil.java  (Removing Groovy just made things easier for me)
helpers/MDCInsertingServletFilter.java
net/JMS*.java  (Gutted all JMS features)
selector/servlet/*
ViewStatusMessageServlet.java

I also commented out some features to allow compilation that I figured I wouldn't need (mostly relating to Groovy).

So, I got logback-classic to compile but for the life of me I can't seem to overcome a NoClassDefFound error for slf4.LogFactory. I've tried everything I can think of to ensure a clean path  but I keep getting this error.  I even unwrapped slf4j and compiled it into my logback4android project.  Again, everything compiles nicely but it gets confused trying to load that class.

If anyone has any ideas or suggesstions I'd love to hear them.

Robert Schmid



On Aug 6, 2010, at 4:36 PM, Ceki Gulcu wrote:

On 06.08.2010 23:25, Robert Schmid wrote:
I am about to implement an appender that I can use on Android. I'm
guessing it won't be much more difficult than doing the same from log4j.
The primary problem is that we can't really use java.io.File to access
the file system. Android has its own File access API. I believe that
this will be as simple as extending RollingFileAppender and overriding
methods as needed to swap out the File access apis.

Sounds good.

Can anybody spot the flaw in my thinking? Are there other pitfalls I
need to worry about?

No, not really, Anyway, if you run into trouble, just holler.


Robert Schmid
_______________________________________________
Logback-user mailing list
Logback-user at qos.ch<mailto:Logback-user at qos.ch>
http://qos.ch/mailman/listinfo/logback-user


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/logback-user/attachments/20100809/f53653a5/attachment.html>