Microlog4Android V1.0 Released

Finally! After many months of struggling with Microlog4Android, the first official release is here. The core is the original Microlog code, but it is re-written to take full use Java SE features. For example, no Vectors are used. This means that the logging is faster than it was in Java ME. One important addition is the support for SLF4J. This should make it easy to migrate if necessary. This might also be an addition to future versions of Microlog. This way it should be easy to share code between Java ME and Android. The most important appenders are there as well.

Please download it from here. As always, any feedback and comments are welcome.

Microlog, Microlog4Android, SLF4J and Other Stuff

Right now a lot of interesting stuff are happening with both Microlog and Microlog4Android. I have been working with Microlog, while Jarle has been working on Microlog4Android (M4A). Let me start with Microlog.

I have started the work on Microlog V3.0. To start with I have been able to make the structure a little bit easier. For example I have removed some abstract classes, like the AbstractFileAppender. This was created for one purpose only, to be able to re-use parts of the file logging functionality between Microlog and M4A. A nice side effect of this construction is that we save some memory, both in terms of the memory footprint and run-time memory. Some bugs are fixed and there are some minor improvements.

Even though Microlog is my long time sweetheart, the most exciting things are happening within the M4A project. When moving the code from the Microlog to M4A, we skipped a lot of code. It was the core and only a few appenders that was moved. Working with the Android platform is quite different and the needs are a little bit different. For example, there is not really a need to log to the console. Instead we have replaced the ConsoleAppender with the LogCatAppender. This works as the built in log classes.  The reason for moving Microlog to the Android platform was to give Android developers more opportunities than the built in logging facilities. It is possible to use the logcat tool to log to file, but in that case you do not get the normal logcat logging in Eclipse. I have never heard of any way of logging to a file on the SD card or on the device, using the Android logging classes. With M4A it is possible to log to a file on the SD card. Just use the modified FileAppender to use M4A to log to file.

Another unique feature in Microlog is the ability to log to a remote server. This far we have the HTTPAppender which logs to a HTTP server. This is definitely something that is not possible with the standard Android logging facility. The HTTP logging is ideal for field test or similar, where the developers need to collect logs in a central place. No need to transfer log file manually. Note that during the development it might be more natural for individual developers to log to a file.

But that is not all! The most prominent addition is the SLF4J implementation. This gives you as a developer freedom to change the logging implementation whenever you feel like it. For example you want to use M4A during development for file logging, but want to remove the logging at deployment time. Just replace the M4A jar with the NOP implementation. If you want to revert back to good old Android LogCat logging (only), use the SLF4J implementation.

Last but not least, we have changed the PropertyConfigurator to read configuration files from an Android resource directory. The microlog.properties file could either be stored in the /res/raw or the /assets directory.

For those of you that want to try it out, it is available for download at: http://code.google.com/p/microlog4android/downloads/list
 
Please note that the latest release (V0.5) is rather experimental, but please try it out and give us feedback.

Starting the 3.0 development of Microlog?

What should it take to upgrade Microlog to 3.0? A while ago I release V2.3.4 of Microlog. There was only one "small" change, the Microlog instrument and instrument example modules were activated once more. They had not been part of any previous 2.X release. But was it a good decision to make only a patch release for such change? I must admit that I think this was an incorrect decision. The change was big enough to make a minor release or even a major release. What should I do to solve the situation right now?

I think the best solution would be to make a major release, that is that I should make a Microlog V3.0. This makes it possible to make some other changes that I wants to do. The changes that first comes to mind are these:

• Add the logging level NONE.
• Remove the Android module
• Remove the Amozon S3 module
• Cleanup the PropertyConfigurator
• ?

Some explanation might be in place. Adding the Level NONE gives the possibility to stop the logging without removing the logging from the code. This is sometimes used for production builds, with the possibility to enable logging after distribution. The feature has been asked for many times. To be honest I do not remember why this has not been implemented before.

Removing the Android module is for obvious reasons, since we have forked the Android parts this is no longer necessary to keep in the Microlog project. But is might not be obvious why to remove the Amazon S3 module. For me this was an experiment, but not something that turned out well. It is big and clumsy. A 3rd party library is used for the SOAP communication which also adds to the size. Fortunately it is kept in a separate jar. Thus only developers using the Amazon S3 modules are affected by this. Another drawback is that we need to maintain this module. I feel that I rather spend time on maintaining the core and other modules that are more important. But this is something that certainly is worth discussing. What do you think?

Cleaning up the PropertyConfigurator is something that I have wanted for a while now. When adding the hierarchical logging support in V2, I kept the original configuration possibilities. This is not wrong. However there are parts in the code that could be shared between the Microlog classic configuration and the new configuration. The parsing of attributes could be replaced by a separate StringTokenizer. All in all I think that the size of the configuration classes could be slimlined.

I guess that there are some more parts that could be improved and/or added to the list for Microlog V3. This was all that I could think of right now. Do you have any suggestions?

Ego Surfing - Microlog4Eclipse

Sometime I do some ego-surfing. I check if there is anything written about Microlog or any other open source projects that I am involved in. One funny thing is that I found the podcast that I and Darius Katz was part of as a ringtone. Maybe it is a bestseller? :) But I just found a more serious project, namely the microlog4eclipse project. It is an Eclipse plugin to simplify the usage of Microlog. Or as it say on the project page "Plugin for j2me microlog logger based on android adt plugin". I wonder if they are using the Android part of the Microlog library. There is no download available at the moment. I will investigate this further. Curious to check it out. It is interesting that someone is actually writing a dedicates Eclipse plugin for Microlog.

Some Words about Microlog and Some Maven Stuff

As you faithful readers know, I am a believer in “Release early, release often”. Therefore I have tried to streamline the release procedure as much as possible. It must not feel like a burden to do a release. In fact it should be as fun as watching a comedy film, almost at least. But this time it was not very fun.

About two weeks ago, one of my fellow Microlog developers committed some changes. It was time to make a new release! I always start out with the deployment of Maven artifacts to the Sonatype repository. Ever since I changed from using the website at SourceForge as a repository, to the Sonatype repository this is a process that works like a charm. It usually takes a little more than two minutes to do this. After that point the artifacts are available on a Nexus staging repository. If something is wrong, you can drop the release. If  the release seems to be ok, you have to close and promote the artifacts. When you close the staging release, a validation takes place. It checks if everything is ok.

The validation process has always worked for me since I first got it right. But not this time! It was complaining about missing information in all the module, information that is available in the parent module. As a coincidence, or not, a discussion about this was started on the Sonatype forums. As it turned out, this was a bug in a new validation scheme. There was a workaround, but I did not feel that it was worth it. From my experiences I could conclude that the folks at Sonatype usually fix this in a day or two. This time it took some days more.

When the validation bug was fixed it was time to give it a try again. This time the validation was complaining about a file not being signed (site.xml). A file that should not be signed, at least not according to me. This was part of the parent module. To get rid of this problem I decided to make a new sub-module for the site generation and try if I could sign the file this way. After a while I was able to sign the file. However now the site was not generated correctly. Not good! I moved the site.xml file back to the parent module, but kept the module since I thought the site generation was good anyway. The site generation worked again, but the file was not signed. Time to google. Now I found a solution that should work; disable the deployment of artifacts from the parent module. It worked, almost anyway. Now none of the artifacts was deployed. More googling. Aha, it is possible to disable the inheritance of some build plugins. Now it worked the way I wanted. Nice! The process of finding out how this should be done took me “only” about 4 hours. But there was one bonus; I could now disable artifacts modules that was not very useful to deploy. For those who wonders how to disable artifacts deployment, take a look at this helpful article.

Finally I managed to make the release and deploy the artifacts to the Sonatype repository. The artifacts are there in Maven central as well. For those of you who are interested, the version is now 2.3.5. Enjoy!

R.I.P. Kenai - Microlog4Android has been Moved

I admit it. I was wrong. It is not business as usual for microlog4android. Yesterday I got an e-mail explaining that Kenai will be shutdown. But fortunately there are other hosting options. I wanted to move the project as fast as possible and have a simple solution. I was recommended by my esteemed colleague Hugo about using Google Code together with GitHub. Google Code allows a project to use other service, such as GitHub, when Google Code  is not sufficient enough. Moving the source code was rather simple. The part that took time was to generate a new SSH key for my new computer. The nice thing with git is that all the history is preserved.

To move the source code from the Kenai git repository I did the following:

git pull git://kenai.com/microlog4android~source-code-repository

git remote add git@github.com:johanlkarlsson/microlog4android.git

git push origin master


It was as simple as that. The first line was needed to pull the source code out from Kenai, since I had no backup copy on my new computer. So for a user with the code on his computer, it would be even simpler.

Right now it is time for me to relax a little. I know I have a lot of things to do tomorrow at work. Please stay tuned for more updates about microlog4android.

The project:
http://code.google.com/p/microlog4android/

The source code:
http://github.com/johanlkarlsson/microlog4android

The Future of Kenai?

As I wrote in an earlier article, the Android part of Microlog has been forked into a new project. The project is hosted on Project Kenai beta. This is Suns offering for open source project. With Oracles acquisition of Sun this project seems to be endangered.  But I am not sure how it will be affected. If it is going to be changed, I sure hope that the projects will get support for the migration if any. For more information, read the article about the subject on Kenai's blog.

I guess we have to continue with business as usual for microlog4android.

Newsflash! Microlog for Android - microlog4android

As you might know, Microlog has support for logging on the Android platform. However it has been living a rather discrete life in the shadow of the rest of Microlog. The other day I chatted with one of the other Microlog developers (Jarle) and we decided that it was suitable to create a new project for Microlog support on Android. We aim to re-use the Microlog core, but to optimize and such for the Android platform.

But why should I care? Android already has built in logging support that works rather well. I think that there are a couple of reasons for using Microlog on Android:

• Log4j API
• Resource effective
  
• Remote logging
  

Many people are used to the Log4j API when it comes to logging and prefer it over the Java logging API (which is used on Android). I have spoken to several users of Microlog and they have praised that it uses the Log4j API.

The Microlog has been built from scratch. It has been designed to be used on devices with a small amount of memory and with reduced processor capacity. Log4j on the other hand contains a lot of legacy code and has been used on computer with many times the capacity of an embedded device. For example Log4j contains a lot of classes that are there for being backward compatible with older releases.

The Microlog library has support for logging to remote servers and devices. This is not something that is built into the logging API found on Android. Remote logging is something that is very appreciated in Microlog. My guess is that it would be nice for Android developers as well.

As mentioned before, the project was registered a couple of days ago. Notice that we are in the startup phase and no release is available yet. We decided to use Kenai.com, since SourceForge does not meet our expectations. The project is called microlog4android. As always; any contributions are very welcome. Please contact me if you are interested in the project.

It would be interesting to know what you think of this idea. Is this something that is missing on the Android platform? Or is the built in logging enough for you?

Some Thoughts about Android

As a embedded developer working with mobile phones, there is a new interesting kid on the block; the Android platform. If you are a mobile developer you most certainly had heard of it.

The interesting thing from a Java developer point of view is that all the APIs are in fact in standard Java APIs. But the developers of the Android platform has selected a subset of the Java SE APIs. Thus the implementation is not a fully compliant Java implementation. Further on the code is not executed as bytecode. The source code is first compiled to bytecode. In the second step the bytecode is converted to Dalvik bytecode. The Dalvik bytecode is then executed on a Dalvik Virtual Machine. The Dalvik is optimized for devices with limited power. According to the people behind the Dalvik VM, it should consume less power than a normal JVM.

I have bought a HTC Hero to have the opportunity to use an Android phone and to develop applications for the Android platform. It is possible to execute a Android application on an emulator, but still I think there is a need to be able to execute on a real device. The emulator is real good and I think that it is very close to the reality. My experience tells me that in the end it is always better to run on an actual device.

As of now I have not developed an real Android application from scratch, although I have attended an Android course. I am really looking forward to making an Android application. If its gets good it would be interesting to put it on Android Market, aka Google Market.

But what will happen to Java ME? I think that Java ME will live long and prosperous, although some programmers that are tired of Java ME will move to Android. The devices that are out on the market today are primarily high end phones. Java ME is found on many low end and mid end phones. What do you think? Will Java ME survive now that Android has arrived?

Microlog Mentioned Again

Maybe a little bit of old news, but I thought I would share it anyway. Microlog was mentioned in this article:

http://weblogs.java.net/blog/editor/archive/2009/11/10/microlog-220-provides-reliable-small-footprint-j2me-and-android-loggi

Powerful Logging in Java ME

The last couple of weeks has involved very much work. First of all I have been preparing the Microlog V2 release. Second I have been writing an introductory article to Microlog. It is now published over at Sun Developer Network. Please read the article and rate it.

http://java.sun.com/developer/technicalArticles/javame/javame-logging/

As always, feedback is very welcome. What do you think about the latest Microlog (V2) release? What do you think about the article?

Using Microlog from Maven

Microlog V2 is available from the Maven central repository, which was not the case for Microlog V1. Thus you need to add the Microlog Maven repository to your Maven project file when using Microlog V1. This is not the case with Microlog V2, since the Maven central repository is automatically searched if no repository is specified. Just add this simple snippet into your pom.xml file:

<dependency>
 <groupId>net.sf.microlog</groupId>
 <artifactId>microlog-logger-core</artifactId>
 <version>2.0.5</version>
 <scope>compile</scope>
</dependency>

This will let you use the core part of Microlog. If you wish to have access to the MIDP part of Microlog, add this snippet:

<dependency>
 <groupId>net.sf.microlog</groupId>
 <artifactId>microlog-logger-midp</artifactId>
 <version>2.0.5</version>
 <scope>compile</scope>
</dependency>

Notice that the version is 2.0.5 which is the latest stable release as of today. For those who want to be on the cutting edge, there is also a snapshot version available. Just replace 2.0.5 with 2.1.0-SNAPSHOT in the examples above.

And that is it! You could now compile your Java ME code that uses Microlog within a a couple of minutes. A lot of projects are using Maven and I hope that you will find this tip useful.

Microlog Development $$$

I have often wondered how many hours I have spent on Microlog. It is countless hours of fun and sometimes frustration. But it is definitely worth it. I guess my wife beg to differ :) Anyway; there is a site called ohloh. This site collects data from the Internet about open source projects. It analyzes the code for a lot of things. For example it checks how well documented the code is. Another interesting metrics is the calculated development cost. Here is a list of the projects that I am involved in:

• Microlog - $ 435,348
• Microproperties - $ 2,955
• Microinstall - $ 12,018
• Voxtr - $ 29,963

Interesting reading. Please notice these figures are not only due to my work, but due to other peoples hard work as well. But is these values realistic or not? What do you think?

Microlog Maven Repository

Right now I am deploying a signed version of Microlog V1.1.1. The reason for this is that the Microlog Maven artifacts are going to be moved to the Sonatype Maven repository. The next step is to upload the latest Microlog V2 to the same repository. By the way; I am going to use Sonatype OSS Repository Hosting. The reasons for putting the Maven artifacts there are many. First of all, using the SourceForge web hosting as a Maven repository is real bad. The primary problem is that I get all sorts of timeouts or other problems when deploying artifacts. For example, I have tried 5 times now to deploy but has not succeeded yet :( The other reason being that I want Maven to be a natural part of the Maven universe. The Sonatype repository is synched with the Maven central repository. When this is done, it is you as a user (developer) that benefits from that. You only need to specify the Maven dependency, without adding any new repositories. When the artifacts have been moved, I will write an article to explain exactly how this is done.

Now I will go back and try to deploy the artifacts once more. It seems that it failed for me.

Microlog V2.0.0 Finallly Available for Download

Today I have finally made the V2.0.0 release of Microlog. Please download and try it out. Feedback is very welcome!

Download it from here: https://sourceforge.net/projects/microlog/files/

The official release news:

"We have finally released the long awaited Microlog V2.0.0. The core has been reworked and very much improved. It is meaner and leaner than ever.

Noteworthy new features:

• New improved configuration
• Hierarchical logging
• HttpAppender with a sample servlet that you could do your logging to.
• More Maven friendly with small modules. This let you use only the part that you are interested in.

Microlog is a small, yet powerful logging library for mobile devices based on the Log4j API. Supports Java ME (J2ME) and Android. Logs to device, to PC or to servers online. Used in all phases from development on emulator/device to outdoor field-testing.

Microlog is licensed under The Apache Software License, Version 2.0 so it is possible to link and distribute commercial software with this library."

Microlog Re-started

Finally! I have now re-started my work with Microlog. The re-start took longer than expected; Maven was giving me a hard time. To start with it did not manage to create a jar archive, but a NullPointerException. Since the compilation worked I find it strange that Maven did not manage to create a jar archive. Very strange! I use Maven 2.0.9 since some other project that I am involved in require that version. Anyway I decided to upgrade Maven to the latest stable version. Voila! Problem solved! Now another problem occurred; the pre-verification failed. Some libraries was included several time, which caused ProGuard to emit a lot of warnings. After a couple of minor changes the build managed to finish without any errors. All in all this took an hour or so. Time that I much rather spend on development, than on fixing Maven related problems.

I finally got around to make what I really wanted to do; implement something that I call aliases. Please let me explain what I mean. A lot of users has complained about being forced to know the name of the Appender and Formatter classes when creating their configuration files, aka properties files. The solution was quite simple. I put an alias in a Hashtable together with the real classname. Let us see how it looked like before my changes:

microlog.appender=net.sf.microlog.core.appender.ConsoleAppender;net.sf.microlog.midp.appender.RecordStoreAppender
microlog.appender.RecordStoreAppender.recordStoreName=MyRMSName
microlog.appender.RecordStoreAppender.maxLogEntries=40
microlog.formatter=net.sf.microlog.common.format.PatternFormatter
microlog.formatter.PatternFormatter.pattern=%c [%P] %m %T

With aliases it looks like this:

microlog.appender=ConsoleAppender;RecordStoreAppender
microlog.appender.RecordStoreAppender.recordStoreName=MyRMSName
microlog.appender.RecordStoreAppender.maxLogEntries=40
microlog.formatter=PatternFormatter
microlog.formatter.PatternFormatter.pattern=%c [%P] %m %T

You could now use the appenders and formatters without knowing their full classname. This goes for all the built-in appenders and formatters. I think this feature is rather handy. What do you think?

Using Your Own Stuff Is Good

Using your own stuff is good! Nothing remarkable about that, almost every developer would agree on that. In fact this is how Microlog once was created. It was created out of a real need and I used it extensively from the beginning. As years has gone by, a lot of contributions has been made. The philosophy behind Microlog is that there should many different logging destinations, each suitable in its on special situations. Which logging destination you choose is a matter of taste and the technical circumstances. As a consequence I tend to use a small portion of Microlog, beside the core classes.

The project I am currently involved in has been running for several months before I joined. The initial team has been wise enough to choose Microlog. When I joined the project, Microlog V1.1.1 was used. Yesterday I was given the assignment of logging some low level details, that potentially could create a lot of logging output. To be able to control the logging with fine granularity, I needed the newest and hottest version of Microlog. Its support for hierarchical loggers, makes it possible to set different logging levels on different classes. In my case I wanted to use TRACE for one class, but DEBUG for the rest of the classes. In my own projects, I usually only import the classes that I really need and leave the rest out. In some cases I have used the binary version of Microlog and ProGuard to keep the packaged Microlog classes to a minimum. The current project is different, Maven is used for building. As such it uses a repository for its jar files.

I added Maven code to use the latest version of Microlog snapshot. When I used it on my own computer this worked like a charm, but one of my colleagues complained that he could not perform a build. It was missing a jar file from the Microlog repository. As it turned out, this jar was missing. It was available for Microlog V1.1.1, but not for the latest snapshot build. It was very easy to solve, just copy a directory and the repository was working the way it should.

Other problems emerged when configuring Microlog. The original idea was that the new PropertyConfigurator should be backward compatible, in order to make it easy to upgrade from Microlog 1.x.x to Microlog V2.0. I found one bug; a property name had changed. This was also easy to fix. Another deploy and the repository contained the fix. The other problem is that I have re-structured the packages, which means that all the appenders and formatters properties have changed. The re-structuring is very important, so I plan to keep the new package names. Although they break the backward compatibility. But since I have changed the major version number, I am not obliged to be 100% backward compatible. When writing this, a new idea has popped up in my head. Maybe I should implement a converter that converts from the old property format to the new property format. Is this a good idea? What do you think?

Using ProGuard to Shrink Microlog

There have been many users that are skeptical to use Microlog due to its size. The current snapshot is around 150 kb, while the latest final release is 127 kb. If you are doing a small MIDlet, this adds considerable overhead to your MIDlet. In normal cases you only use a fraction of all the classes. For example, you only use one or two appenders. The jar contains a lot of different appenders. But there is a solution. The solution is called ProGuard.

ProGuard is an application shrinker/optimizer/obfuscator for Java applications. It can be used from the command line or from your favorite IDE, such as Eclipse or NetBeans. ProGuard is an important tool in your MIDlet development toolbox.

The recipe for obfuscating your MIDlet and Microlog is as follows:

1. Select Window -> Preferences
2. Select the Java ME -> Packaging -> Obfuscation
3. Press the "Browse" button and select the directory where you installed ProGuard.
   
   
   
4. Select Project -> Properties
5. Set the dialog to the value according to this screenshot:
   
   
6. Select "Java Build Path"
7. Select the "Order & Export" tab. Check the Microlog jar like this
   
   
   
8. Select your project. Bring up the context menu (in Windows it is done by a right click). Select "Mobile Tools for Java" -> "Create Obfuscated Package". You should now have an obfuscated jar in the /deployed directory. If you run the project as a "Emulated Java ME JAD", you automatically use the obfuscated jar file.
   

For those of you that are not using Eclipse, you could use the following configuration when running ProGuard from the command line.

-overloadaggressively
-defaultpackage ''
-allowaccessmodification
-dontusemixedcaseclassnames
-keep class net.sf.microlog.appender.MemoryBufferAppender
-keep class net.sf.microlog.appender.ConsoleAppender
-keep class net.sf.microlog.format.PatternFormatter
-injars microlog.jar
-injars yourmidlet.jar

Copy the content and save it to a file, for example proguard.conf. Then you start ProGuard like this:

java -jar proguard.jar @proguard.conf.

By using ProGuard you reduce the size of your MIDlet jar. Unnecessary classes are removed, the code is optimized and obfuscated. And using Microlog does not mean lare overhead to your MIDlet. There are other alternatives to ProGuard, but ProGuard is the most widely and de-facot in the lovely world of Java ME.

Microlog is Still Alive!

It was a while since I wrote about what is happening to Microlog. I myself have not been working very much on Microlog the last couple of weeks. But fortunately there are more developers working on Microlog. At the end of last week, the Microlog project was joined by Jarle Hansen. He has been improving the Bluetooth logging in Microlog, to work better on Ubuntu Linux. He has also written an excellent article on the subject "Using MicroLog over Bluetooth with Ubuntu and Eclipse".

Therefore I have released a new snapshot of Microlog. The snapshot version includes the changes made by Jarle Hansen, as well as some minor changes made by me. The snapshot version is also available in the Microlog Maven repository as well.

Report from Presentation at JavaForum in Malmö and Gothenburg

Last week I did present Microlog at JavaForum both in Malmö and Gothenburg. JavaForum is the Swedish JUG. It was a great honor to be invited to both these places. These are my reflections and thoughts about my presentation.

At the first presentation in Malmö there was around 50-60 people. I knew many of the people beforehand, which made me less nervous. The presentation went smoothly and I got some questions, that hinted me what to improve in the presentation. Unfortunately I did not had time to stay afterwards to get some more feedback.

Driving to the destination in Gothenburg at rush hours was not an easy task. My GPS device was out of battery, so I used Google Maps to find my directions. When no GPS device is attached, it uses GSM cells to figure out where you are. The accuracy is about 600 m in a city like Gothenburg. That is maybe enough when walking in a city to find out where to go, but by car that is not enough. What a shame I was not in a Hollywood movie, where the accuracy seems to much better than that. Anyway I found the place to be and was there on time.

Afterwards I had the opportunity to speak to some people in the audience. First of all I got a question about what Maven help I wanted. It is mainly about getting Maven to generate better packages for the releases. For more details see this discussion.

One other question I got, was "What is the reason for not being able to do printStackTrace() and re-direct it to a log? Or do you have any idea how to solve it?". The thing is that I have not found a way to re-direct to another destination within Java ME. The reasons are:

1. The System.err is final in the System class found in Java ME (CLDC). I do not know why this is, but it hinders you as a developer from setting these to something like a FileOutputStream or similar.
2. The method printStackTrace() comes in different flavors in Java SE. For example, the public void printStackTrace(PrintStream s) is useful to direct the stack trace to another destination than the default one. This is not available in Java

One workaround that works under some condition is to re-direct the output from your Java MIDlet outside the JVM found in your phone. On the Symbian platform there are such applications available. If the problem is reproducible in the WTK, you could run it look you normally do. By using the ConsoleAppender you get both the normal exception message along with the stack trace. BTW do you know any other workaround? If yes, please enlighten me.
That is all for now. Thanks to Björn Granvik and Rickard Thulin for inviting me to JavaForum.