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@qos.ch<mailto:Logback-user@qos.ch> http://qos.ch/mailman/listinfo/logback-user