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

Öredev Reflections

I have just finished 3 intense day at the Öredev conference here in Malmö. As always I have a lot of thoughts, ideas and inspiration after attending a conference. These are my reflections from the conference:

• I was missing a sessions about Android. Everybody is talking about the Android platform, but I wonder how many developers are actually developing for Android. It would be interesting to hear about some real Android projects. But maybe next year we will have some Android sessions?
  
• I was surprised by the session "Design to Development- Collaborating and Communicating Interaction Design". I have never heard of Theresa Neil before. She has some really good ideas. It was about communication between developers and interaction designers. This is something that I could relate to.
  
• My friend and colleague Davor had an interesting presentation called "Snow white and the seven dwarfs". It is a true about Davor (Snow White) and his team of developers (the dwarfs). He introduces the concept of Developers Exploratory Testing (DET), which is a way to do continuous testing in an agile project. The James Bach really liked the way how Davor has taken some ideas by James Bach and evolved them even further. Note: I am one of the dwarfs.
  
• Maven 3.x has some genuinely interesting news. The thing that I would like to try out the most is the new Maven console. I hope that it will help me to do faster builds.
  
• The keynote by Scott Hanselman was interesting. He gave some nice hands on tip for improving your efficiency as a developer.
  
• I have been registered as a Twitter user for some time now. Never used it much for anything other than Microlog news. During the conference I twittered a lot. I used the "I Tweet" Android client. Now it feels like I am hooked on Twitter. The Tweets was displayed on large screens all over the place, so it became very popular for many attendees. In fact tweets about #oredev was on the top list for Scandinavia.
• I attended a session by Neil Ford that was interesting. He is the author of "The Productive Programmer", a book that I recently read. As the name implies it is all about productivity for programmers.
  
• Some interesting stuff going around with the Java app store. I have always wondered why Java desktop applications are so underrated. I hope that Java desktop apps will get more popular.
  
• Ze Frank is very funny. He has a lot of very interesting social experiments going on and some unusual games.
  
• I liked the sauna and dinner on Monday. Did meet some interesting people there like Marc Lesser and Chris Hughes. The Swedish pickled herring on a toast was superb. The main course was Swedish fish, not candy kind, but a codfish.
• In general a very good conference. Of course I am a little bit biased since my company is one of the founders of Öredev.
  

That is all that I could remember right now. I guess that I have missed something out. Here are some pictures from the conference:


Marc Lesser about "Doing Less"

Terrence Barr about Java and Open Source


Theresa Neil about Interaction Designers and their interaction with software developers and vice versa.


Davor speaking about "Snow white and the seven dwarfs".


The Öredev Twitter feed. Notice the comments about Davor's presentation.

The No SQL presentation. To the left Emil Eifrem, Adam Skogman to the right. Notice their new definition of NO SQL.

The multi talented Ze Frank was very funny.

An air safety instruction. Notice the wizard to the right.

Chris Hughes about the secrets of the iPhone. Chris is a very cool geek, just the way a geek should be according to me.
Looking for some bugs?


Scott Hanselman and his keynote.

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."

Mobile and Embedded Community Star Award

During the years I have been involved in several developer forums. Lately I have spent many hours in the Mobile and Embedded Forums at SDN. I have tried to help people with their Java ME questions as much as I can. Someone recognized this fact...

The official news can be found here.

Read more about the "Community Star Award".

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?

Blu-ray, BD-J, BD Live etc

As you might know I am a cineast and a home theater junkie. I have tried to assemble a decent home theater. From time to time I upgrade it to achieve the ultimate movie experience. For several years now, I have been longing for a Blu-ray player. However I do not like to be a early adopter, at least when it comes to hardware. The primary reason is that it is to expensive, the secondary is that the technology needs to be mature enough for me to buy it. In this case it was in fact Java that stopped me. Why? Let me explain.

A Blu-ray player manufactured today is required to include a Java implementation to adhere to the Blu-ray specification. This is called BD-J. The intention with this is to be able to include more advanced menus, games and interactive contents. A Blu-ray disc can contain one or several Xlet applications. For a more comprehensive article on the subject, please download and read my article "Blu-ray and Java". When the MIDlet specification was released, it took several years before there was a decent implementation available. As it seems, it is the same with Xlet implementation on Blu-ray players. Many independent Blu-ray player reviews shows that Blu-ray discs with Java content have longer loading time. For example, it is reported that loading time up to several minutes is not unusual.

The July issue of the Swedish magazine "HemmaBio" contained a big review of several Blu-ray players. The LG BD370 was dubbed "Best Buy" and at a reasonable price. I searched the Internet and found several positive reviews, like this one. Besides the price, it seemed to have very good Java performance. In fact it is par with the performance of a Playstation 3 when it comes to loading times for Blu-discs. It adheres to the latest BD-J version and also has support for BD live. The BD live feature is used to bring live content to your Blu-ray player, such as trailers. For example, the "Transformer" movie let you connect to the Internet and download the trailer for the following "Transformer" movie. Another nice feature is the YouTube viewer. As you might have understood by now, I bought the LG player.

To try the player I bought two Blu-ray discs. I decided one disc while I let my son decide the other one. My choice was the "Pirate of Caribbean: the curse of the black pearl". This is by many considered as a reference Blu-ray disc. Both the picture and sound are great, but it also contains BD-J content. The BD-J content is used for testing the performance on Blu-ray players, since it is rather big. As mentioned before, it could several minutes to load the content. My son choose the movie "Bolt", just because it contained a game. It was a special edition that also contained the DVD version. So this was perfect to test a Java game and to compare the quality difference between the DVD version and the Blu-ray version. Both the picture and sound is considerable better.

I think it is interesting to see Java on yet another platform. It shows how Java is usable in many different environment. Java is finally used in an environment similar to the environment it was originally designed for, that is set-top boxes.

Here are some pictures from me using the new Blu-ray player.

The main menu when starting the Blu-ray player.

The featured videos on YouTube.

The search screen, while searching for the Jayway video.

The Jayway video in normal screen mode.


The Jayway video in full screen mode.

The Bolt game. Notice the localized version. I have not seen this on many computer games today. In the beginning of the game, the instructions are narrated. This is good for kids that could not read.

Appending to a File in Java ME ( J2ME )

Yesterday I was asked how to append to a file in Java ME. I have never done this before, so I could not give an answer. After some research we found a working solution. This article will go through the different ways to solve it.

I first looked into the JSR-75 documentation, but I did not find any solution there. When searching the Internet, the first solution I found was this:

public void appendToFile() {
try {
 FileConnection fileConnection = (FileConnection) Connector.open(
         "file:///c:/other/textfile.txt;append=true",
         Connector.WRITE);
 OutputStream outputStream = fileConnection.openOutputStream();
 PrintStream printStream = new PrintStream(outputStream);
 printStream.println("Some text to append");
} catch (IOException e) {
 e.printStackTrace();
}
}

At first it looks promising. The Connector class specifies that you could add parameters when opening a connection. However the parameters for JSR-75 are not standardized. This solution was mentioned in the Nokia developer forums, so I guess that it works on Nokia phone. The platform that we uses did not support it. Thus this solution is not portable across different Java ME devices. I recommend that you DO NOT use a solution like this.

The next solution I found looked like this:

public void appendToFileFileSize() {

try {
   FileConnection fileConnection = (FileConnection) Connector.open(
           "file:///c:/other/textfile.txt", Connector.WRITE);
   OutputStream outputStream = fileConnection.openOutputStream();
   outputStream.flush();
   long fileSize = fileConnection.fileSize();
   String textToAppend = "Some text to append";
   outputStream.write(textToAppend.getBytes(), (int)fileSize, textToAppend.length());
} catch (IOException e) {
   e.printStackTrace();
}
}

This works but is rather clumsy and does not look clean. Note that you need to call flush() before you make a call to fileSize(), otherwise the size is not guaranteed to be correct. But wait, there is another solution.

public void appendToFileMaxLong(){
try {
 FileConnection fileConnection = (FileConnection) Connector.open(
   "file:///c:/other/textfile.txt", Connector.WRITE);
 OutputStream outputStream = fileConnection.openOutputStream(Long.MAX_VALUE);
 PrintStream printStream = new PrintStream(outputStream);
 printStream.println("Some text to append");
} catch (IOException e) {
 e.printStackTrace();
}
}

The method openOutputStream(long bytesOffset) open an OutputStream and moves the position the specified offset. When the offset is greater than the file size, the position is moved to the end of the file. This is an clean and portable solution.

My Top-10 Favorite Development Tools

The other day I got a question about which are my favorite tools, i.e. what is in my Java developer toolbox. I was asked to list my top-10 favorites. This gave me the inspiration to write a blog article on the subject. So here goes my top-10 list of favorite tools.

1. Eclipse
   The basic tool in any Java developers toolbox. The IDE to use.
   
2. Beyond Compare
   This is the best comparison tool that I have ever used. There are some open source comparison tools, but they do not match up against Beyond Compare. I think that Beyond Compare is worth every penny.
   
3. FindBugs
   FindBugs is used for finding bugs or potential bugs in your Java code. I use the plug-in version in Eclipse and use it from Maven as well.
   
4. Microemulator
   An Open Source Java ME emulator. Lets you test your Java ME applications. The drawback is that some JSRs are not implemented yet. Most notably is JSR-205 and JSR-211.
   
5. Virtual Box
   This lets me run Ubuntu Linux inside Windows Vista. No more dual boot configurations.
   
6. Subclipse
   Lets you use Subversion inside Eclipse. The Subversive plug-in is a better tool, but the Subclipse tool works better with the Maven plug-in-
   
7. Tortoise SVN
   Whenver you are in the Windows file explorer it is nice to have access to Subversion. I have set it to use Beyond Compare when doing file comparison.
   
8. Maven
   I did not really like Maven from the beginning. At the time I was a big fan of Ant. Maven contains some functionality that is not available in Ant, such site generation. I
   
9. Eclipse Maven plug-in
   The name speaks for itself, it gives the ability to run Maven from Eclipse. There is also the pom and Doxia editors that are really good.
   
10. Eclipse MTJ plug-in
    The Mobile Tools for Java lets you perform the necessary Java ME tasks.
    

This it is. Do you think that I have missed some tool? Is something on the list that in your opinion that should not be there? Looking forward to her

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.

"What is Soo Special About Microlog?"

"What is So Special About Microlog?", this was the first question I got this morning when arriving to work. This was asked by one of the Java Enterprise specialists at my work. Hmmm... let me think. I was a bit paralyzed by the question, although I should not be. This is not the first time I get this question, I get this question a lot (from people not working with Java ME).

My first answer was "size!". The Log4j jar is 389kB, but Microlog is about 110 kB. But the actual jar size is not what is interesting, but the overhead that Microlog add to the jar. In normal cases it is somewhere between 30-40 kB, depending on what you decide to use. I consider this to be little overhead considering that you get two appenders with two formatters and the configuration framework with the ability to configure via properties files and/or JAD settings files. Plus you get the ability to setup your loggers in a logging hierarchy. All in all, the small size of Microlog is one of its benefits.

My second answer was "remote logging". Log4j contains some remote logging destinations, like syslog daemons and JDBC. Microlog has also support for logging to syslog daemons. This is one of my personal favorites. It is easy to setup a syslog daemon and you get the logs on the server directly. I choose not to implement JDBC support in Microlog. First of all, it makes me sick to think about setting up a JDBC server. Secondly there is not many JDBC drivers available for Java ME with CLDC. Instead I implemented support for logging to Amazon S3. It is easy to setup and you have access to very much storage for a cheap price. Right now you can upload 1 GB for $0.03. Compare this to the price of setting up a JDBC server. You cannot work for many seconds before you have used up your $0.03! It is also very pratical to log to Amazon S3. For example you log to a file, when the file gets to big or when you log above a certain level, the file is copied to the server. As far as I know this is a unique feature, this is not implemented in Log4j and I do no know any other logging library which has suport for Amazon S3. And that is not all; Microlog has support for sending an SMS/MMS or e-mail as well. Log4j has support for e-mail which is based on a simple SMTP client. Micrologs implementation is a little bit smaller and smarter. It uses the Wireless Messaging API (JSR-205) to send an e-mail. The actual assembling of the e-mail and the sending code is less than 30 lines of code. Quite impressive if you ask me, but I am a little bit biased. What do you think? These are the most important remote loggers, but there are more. Please take a look at the Microlog documentation to find out more.

The second question was "how do people do logging if they do not have Microlog?". My answer was "I am not sure, but I guess that they log to the record store or to a file". But if you choose to log to the record store, they also need to implement some kind of log viewer. The data is stored as a byte[] in the record store, which is hard to read right away.

After some further discussion with my collegue, he ask me "...then people must be very happy when the find out about Microlog?". Yes in fact they they are. At least the people that I have spooken to. Of course, sometimes people have some issues with Microlog that they do not like or like to improve. But I always try to listen to the feedback I get and improve Microlog accordingly. In fact most of the important changes are based on feedback. So please continue giving me more feedback about Microlog.

Available on Twitter

I am now available on Twitter. Use the link to the left if you want to follow me on Twitter. This is kind of a experiment for me. I am not sure whether I like Twitter or not. But at least it is worth a try.

SourceForge Community Choice Awards, Please Vote for Microlog

Every year SourceForge honors the most popular projects in the Community Choice Awards. The first nomination period for this years awards has started. Read more about in this press release. If you find Microlog useful, please nominate it by going to the SourceForge project page and press the nominate button.

Edit: For your convenience, I have provided this link to get to the right place directly.

Preparations for a Microlog Presentation @JavaForum in Sweden

It is now official; I will be talking about Microlog at the next JavaForum meeting in Gothenburg. JavaForum is the official Swedish JUG, with 3 different branches in Stockholm, Gothenburg and Malmö. The talk will be held in Gothenburg.

I am really looking forward to it. Tonight I have been preparing myself. Most of the time I have been coding. I want to improve the V2.0 branch. The goal is to stabilize the API before the presentation. My hope is that I get many downloads after the presentation. But I have also started to do a first draft of the actual presentation. I only have a 30 minute slot, so I need to carefully select the pieces that I want to be included. This is a nice little challenge. Me like it.

Android, Android, Android and Some More Android

Android is getting a lot of attention right now, both from me and a lot of other people. Recently I attended a breakfast seminar about business opportunities with Android. The author of the book "The Busy Coder's Guide to Android Development", Mark Murphy, gave an interesting presentation on the subject. After a brief technical introduction, Mark spoke about the business opportunities. As I gathered, he mostly used the classical open source business opportunities, more or less. Nevertheless the presentation was good. The most interesting part of the breakfast seminar was actually the fact that it was really crowded. I would guess that there was around 200-300 people there, which is very much for a breakfast seminar i Malmö. I meet a lot of old colleagues and all was very positive about Android.

I have just attended the "Advanced Android" course by WayEducation. It was really good and gave insight into the inner workings of the Android platform. I am looking forward to start programming Android for real, in a real project. But that is just around the corner, since it is part of our product backlog.



Last but not least I have ported some parts of Microlog to work on Android. The core is the same for Java ME and Android, but opening a file or a network connection is different. On the other hand writing the actual data is done the same way, e.g. to an OutputStream. This shows that even though Android not officially is Java, we could re-use Java code.

It will be interesting to follow what happens with Android, the platform, the community and the phones. Only time will tell.

What are you opinions/experiences with Android?

Detecting Flight Mode (Kind of) in Java ME on a Nokia Mobile

The other day I wrote an article about how to detect flight mode. But it did not cover how to solve it on a Nokia phone. On a Nokia phone, like a Sony Ericsson phone, there is no system property to detect flight mode. On the other hand, if we asume that what we really are interested in checking if the network is available or not, we have a solution on a Nokia phone. If we check this, we can make the MIDlet smart, e.g. setting it in off-line or on-line mode.

The solution is very simple:

String networkAvailable = System.getProperty("com.nokia.mid.networkavailability");

if(networkAvailable.equals("available")){
// Warn the user that the network is not available and off-line mode is used
}else{
// Network available => we could work as normal.
}

The trick here works on the Nokia S60 platform FP3, or later. I have not found out a solution on a Nokia S40 phone. Does anyone know?

Detect Airplaine/Flight Mode on Motorola and Sony Ericsson Mobile Phones in Java

Many MIDlets communicate with a server and/or connects to the Internet. If the user enables airplane/flight mode, the MIDlet should be aware of this. This way it is possible to set the MIDlet in off-line mode automatically and inform the user when trying to access the net. It is much nicer to get a dialog saying "Sorry you are in flight mode, you cannot this and that", instead of "Failed to connect to server". This article describe how to do this in Java ME (on some platforms).

There is no API that enable a Java ME developer to access the flight mode. The key here is to get a system property via the right key, no pun intended :) This is done via a call to System.getProperty("key"). The key differs from platform to platform.

On a Motorola mobile phone, with Motorola OS, this is done like this:

String airplaneMode = System.getProperty("com.mot.network.airplanemode");

if(airplaneMode.equals("true")){
// We are in flight mode
}else{
// We are not in flight mode
}


On a Sony Ericsson mobile phone it is a little bit different, since there is no system property to detect if we are in flight mode or not. The trick here is to use a key that detects the Radio Access Technology (RAT) used at the moment. This returns null if the radio is turned of, which it always is when in flight mode. The code looks like this:

String flightMode = System.getProperty("com.sonyericsson.net.rat");

if(flightMode == null){
// We are in flight mode
}else{
// We are not in flight mode
}


And that is it! Pretty simple, but still powerful. I hope this trick is useful for you.

Microlog Maven Help Wanted

As you might know I am working with the new Microlog V2.0 release. From the beginning I knew that I needed to do some re-factoring of the code and add some new functionality. The re-factoring was fairly easy, but the logging hierarchy and the new configuration has taken more time than expected. What is bothering me right now is the fact that there is a lot of other work to do. The most work is Maven related. I am not very fluent in speaking Maven, so it is a huge step for me. But coming to think about it, I have found out that I could use the power of open source development; getting help from others. I have therefore posted a "Maven Help Wanted" in the Microlog forums. But I might ask you, the blog readers, about help as well. If you are interested, please contact me and be a part of the Microlog project. For your convenience I have pasted the original post here. Please join the discussion in the Microlog forums; https://sourceforge.net/forum/forum.php?thread_id=3260687&forum_id=464718

Hi,

I am working hard on the Microlog V2.0 release. But I have found out that I need help with some Maven related tasks.
Could you PLEASE help me out?

I feel that I need to focus on the coding work and I am not very good with Maven.
If you are good at Maven it should be easy to do the tasks that I suggests.
So help is really, really very much appreciated!

Here comes a description of the tasks that I feel that we need to perform.


===== Maven Tasks =====

* Two distributables; one binary and one source code distribution.
* Get the deploy task to work. The Maven repository is not up-to-date.
* Enable the Eclipse Maven plug-in.
* Write a "Developer Getting Started Guide". How to check out, install Maven, use Maven to create Eclipse projects, etc.
* Include the Android project in the Maven build.
* Get the testing and code coverage to work.



A more detailed description of the task "Two Distributables":

* There binary distribution needs to the broken down to small jars. I suggest the following jars:
- microlog-core.jar
- microlog-common.jar
- microlog-midp.jar
- microlog-spot.jar
- microlog-android.jar

Note: these correspond to the new sub-packages found in Microlog V2.0

* The binary distribution should have a directory structure like this:

/jars - all the jars
/bin - all the servers as binary jars or even better as .exe files.
/docs - all the docs
/docs/javadocs - all the javadocs

* The source code distribution should have all the projects packaged in their own directory, like this

/micrlog-core
/microlog-servers
/microlog-instrumentor
... etc


I could have missed out on something, please comment on my suggestion. If you want to perform a task, please inform the rest of us.
I will create tasks in the SourceForge task list, so we can keep track on the progress of our work.


Any takers?

Setting the Locale in the WTK Emulator

Sometimes it is useful to how your MIDlet works with different locale settings. One solution is to install the MIDlet on a phone and change its locale. This should be easy to do on most phones. However it is useful to do this on the emulator as well. This article teach youo how to do it.

You have basically two ways to do this:

1. Change the locale of your operating system
2. Change the locale manually in your wireless toolkit.

I have Windows Vista and I have not get the first way to work. There is a dialog called "Regional and Language Options". All the settings are set to Sweden/Swedish, but still the emulator does not change its locale. I have not found out what I am doing wrong. Fortunately the second option is fairly easy to perform.

First you have to find the emulator.properties file. In Sun's Wireless Toolkit this is found in C:\WTK2.5.2\j2mewtk_template\wtklib and in Sony Ericsson SDK it is found in C:\SonyEricsson\JavaME_SDK_CLDC\WTK2\wtklib.

Then you should search for this property:
microedition.locale

In my installation it locked like this:
microedition.locale: en-US

The code consists of two parts; the language code and the country code. These are separated by a dash ('-'). Notice that this is not as in Java SE, where it is separated by and underscore ('_'). The language codes are defined in ISO-639 and the country codes in ISO-3166. In my case I changed it to:
microedition.locale: sv-SE

All you have to do now is to save the file and restart the emulator. Notice that this does not change the locale of the emulator, it only changes what is returned by System.getProperty("microedition.locale"); In my current project we use this to load the correct resources. Thus we need to test how the different strings are looking in different languages and screen resolutions.

Microlog Recent Updates

It feels like I have spent ages on re-factoring the Microlog code. When I look in the rear mirror I see two things that has caused the slow progress. First of all there has been a lot of hard decisions that has been made. For example, how should the setup of the logging hierarchy work like? Should I use the same approach that is used in Log4j or should I invent a new and clever way? The answer is that I used the Log4j way, but adopted it to Microlog. The second problem has been the lack development time. Not much to say about that, Microlog is a project that I do on my spare time. Last but not least, everythings seems to take more time than originally planned.

But what has happened? The biggest change must be the new configuration. The configuration has been centralized and I use dependency injection to inject my properties into Microlog. The properties are fetched using Microproperties. This is in fact the first project where I have used Microproperties. This is good since I managed to improve the Microproperties source code along the way. I have spent many hours writing tests for the logging hierarchy and improving the code along the way. As always, I have commited the source code very often. As such the code in the source repository is very much in flux. Do not expect the API to be stable for yet a couple of weeks.

The coming days I plan to adopt all the Appender classes to comply to the new configuration. A nice side effect is that the code will be smaller. Also I will test out the HttpAppender. It is implemented as it is now, but not tested against a server. This is a much awaited feature. I am really looking forward to make this code available for all Microlog lovers.

Please be patient! I am certain that the new version of Microlog will be worth waiting for.

Manifesto for Software Craftmanship

This week I signed the Manifesto for Software Craftsmanship. When I read the book "Software Craftsmanship: The New Imperative", it kind of rocked my world. The book dissects most of the accepted software engineering principles and offers an alternative view. Since I was fostered in the software engineering school, the book questioned all that I believed in. But I really liked the book and its pragmatic view of software development. The manifesto is built on the ideas in the book.

The Manifesto for Software Craftsmanships looks like this:

• Not only working software,
  but also well-crafted software
• Not only responding to change,
  but also steadily adding value
• Not only individuals and interactions,
  but also a community of professionals
• Not only customer collaboration,
  but also productive partnerships

If you wish to sign the manifest, just visit the homepage. There is also a Software Craftsmanship group at LinkedIn.

What do you think of the manifesto?

Premature Generalization is the Root of All Evil

Finally! I have now finished the first reincarnation of the new logger hierarchy for Microlog. It is a very simple tree structure that keeps track of all the created Logger objects. I choose to do a specialized tree implementation for the purpose, not a general tree implementation. Since there is no tree implementation in Java ME, it could be tempting to do a tree implementation for Java ME. When finished this could be re-used in a lot of other Java ME projects. This got me thinking about those good old days when I was a junior programmer, just fresh out of school.

I was involved in a research project with the purpose of showing the opportunities with an embedded device with an ethernet connection. The embedded device contained a simple web server that was equipped with simple CGI support. My assignment was to create a web pageswith a Java applet for administration of the embedded device. This was actually a proof of concept study. If we managed to convince our product managers about our genius invention, we would of course re-use the code for the real product. So far, so good.

I made a very ambitious design before even starting to do some coding. I can tell you, my manager was really nervous when I did not start code immediately. "No worries, good design is important for fast and good implementation. You need to be prepared really good before starting your implementation!". This was how I was taught. Anyway I managed to do a real fancy design, with many really nice-to-have-classes. I ruled the world of design and my way to fame and glory was laid out for me! As part of the design I did a very general API for the communication. General design is good, I reasoned. This was a BIG mistake!

When we were closing in on delivery date for the demonstration, I had made the general network communication. However I was not finished with real implementation, the parts that was vital for the demonstration. Anyway I was finished about 30 minutes before my project manager was going to leave for the airport, to meet the people who was sponsoring our research. I was tired since I have worked all night and my project manager was not happy. For me it was embarrassing that I was not able to deliver something that I was proud of and I was to close to the deadline. My project manager did manage to do a successful demonstration. Finally the management decided to make our prototype into a real product.

After a couple of weeks it was decided that we was going to use another low level protocol for the communication. It turned out that my general design was useless, since I did not anticipate all the aspect of the problem. But what did I learn from this rather embarrassing moment of my life as developer?

First of all I realized that I do not have the powers, like Nostradamus, to see into the future. I also came to the conclusion that you have to know the domain, before making any generalization. You have to do your first implementation in that domain, before you should make any general design. When you continue to evolve your product, you can figure out what parts of the code that is reasonable to generalize.

So I invented a rule that is "Premature generalization is the root of all evil design". It is of course inspired by "Premature optimization is the root of all evil". Nonetheless I think it is a good rule. This is why I choose to do a specialized tree structure for Microlog, instead of making a more general tree implementation. I have seen the phenomena of "premature generalization" in many projects since. For some reason it tends to be junior developers who fancies these general designs. Today many more people learns design patterns, than when I finished school. There is a big risk that you use to many design patterns, without really understanding the consequences. I prefer to get the code working and to deliver it in time for the demonstration. When adopting my golden rule stated above, this is not a problem. Thanks to agile methods, like Scrum, you are forced to make your application ready for demonstration early on. But that is another story.

Microlog Group @ LinkedIn

One networking forum that I really like is LinkedIn. It is a proffesional networking forum, not focusing on the social aspect like Facebook. I have learnt to know a lot of people through LinkedIn. Many of my present and former collegues and friends are there as well. There are many interesting groups at LinkedIn, like the FOSS Proffesionals Group.

I have had the idea of creating a Microlog group lingering around in my head for some time. During the weekend I finally decided to create a Microlog grup. When the decision was made, the registration was simple. I used the new project description and added a group description. Unfortunately the existing Microlog icon did not comply to the required criteria, but I settled with the LinkedIn default icon.

Please join the Microlog group at LinkedIn.

How to do Logging

I tend to get into a lot of discussions about logging. It could have something to do with my Microlog development. Sometimes I find it hard to argue what is good practices when it comes to logging. So I searched the Internet and found these good articles on the subject:

• 7 Good Rules to Log Exceptions
• 7 More Good Tips on Logging

I hope that you read them thoroughly, because the are definitely worth reading. But until then you are maybe interesting on my comments about them?

Starting with the first article, I must say that all of the tips are really good. From my point of view, the last rule "7. Do not log with System.out or System.err" is especially important. The first sentence says it all "Always use a log framework, it can handle logging better than you." Of course I want you to use a logging framework. If you are working with Java ME or Android development, please try out Microlog!

The second article is a little more general. The first advice is a little bit tricky; "No debugging logs in production". Microlog has no built-in feature to solve this, so I usually recommend to use the pre-processor found in MTJ. If you are running in other environments, like vi, you could use the ProGuard pre-processor. The second advice "Look through your logs" is easy to do with Microlog, if you log to a server. Microlog has the capability to log to several types of servers. The easiest would be to log to a syslog daemon or to Amazon S3. Most syslog daemons have some sort of filtering feature and export functions. This should make it easy for you to filter out the interesting stuff. The 3rd rule; "Never log locally" is as you now understand fairly easy with Microlog.

I hope that these articles will give you some good advice that you will be able to use.

Microlog & Microproperties Updates

This weekend I decided to start the replacement of the old Microlog configuration with the new one; Microproperties. Ironically this work was to copy the file reading part from Microlog to Microproperties. When this was done and tested, I decided to do a new Microproperties release. This is the new V0.2.0 release. When this was done I added Microproperties V0.2.0 to Microlog.

However this weekend is approaching its end and I decided to do the first snapshot release of V2.0.0, before continuing my work. The Android extension is included in this release. My hope is that developers who prefer the Log4j API will find Microlog for Android an interesting alternative. Please download and try it out!

Using Microlog for File Logging on Android and Viewing Files on Android Emulator

My goal yesterday was to re-factor the FileConnectionAppender in Microlog. I wanted to separate the logging part from the actual file writing. The logging should be in an abstract super class, while the file writing should be in the the concrete class. The purpose of this exercise would of course to be to support file logging on both Java ME and Android platform.

It took some time to create a good structure in the new AbstractFileAppender and the FileConnectionAppender. When this was done, it was a piece of cake to create the FileAppender (for Android). I used the Eclipse class wizard to create a sub-class to AbstractFileAppender. Most of the time was spent browsing the Internet and looking in the Android documentation. Then it was a matter of implementing a handful of methods. I had never tested to create and write to a file on Android before, but I was curious and executed the code directly when most of the methods was finished. This excluded the flush() method for example. The diagram below shows the new class structure.



The next step was to figure where to find the log file. It was not long time before I found a file with a .img extension. From some documents found on the Internet, I could gather that this was a disk image. But how do I read the data found in the disk image? As it turns out there is several ways to do this:

1. Use the command line tool called adb
2. Use the file browser found in Android DDMS (Dalvik Debug Monitor System)
3. Use the file browser that is part of the Android plug-in for Eclipse.

I will show the 2nd way. If you manage this, you will almost certain be able to the 3rd way. All those shell lovers will have to take a look at the documentation for adb.

You start by typing ddms in your shell window or command prompt, depending on your operating system. This will bring up the DDMS tool. Select the device and use the Device->File Explorer... menu to access the file explorer, see picture below. You could now browse the file system in your Android emulator. In our case we browse to /data/data/net.sf.microlog.android.example/files. This is where you will find the file microlog.txt. If you wish to see the content of the file, which I gather that you do, you press the button marked yellow below. This will pull the file out of the Android file system to your file system. You get the chance to select where you want to save. Pick up your favorite text editor to view the marvelous content of your log file.




It is as easy as this to view a file on the Android file system. I hope you found this tip helpful.

Microlog4Android

I have continued with the re-factoring of Microlog. Tonight my plan was to re-arrange the package structure to separate the Microlog core from the rest of the code. One reason for this was to make it easier to make different flavors of Microlog. The Microlog core should be possible to execute on CLDC. The plan was to move the MIDP specific classes to its own package structure. One new flavor that I had in mind was the Android flavor of Microlog. Many people have asked me about Microlog on Android. My answer has always been something like "It should work on Android, at least the core.".

After the re-factoring it was time to prove my point, that it is possible to execute Microlog on Android. And it did! The setup was simple, it was Microlog with a ConsoleAppender and a SimpleFormatter. Not so very much at the moment, but I think it is a good starting point.

During the process I learnt that it was in fact possible to see the System.out.println() statements. Many people claim that it is not possible to see the System.out.println() in the Console. That is true, but it is possible to get hold of the prints. The trick is to show the "LogCat" view. This is activated this way:

1. Select "Window->Show View->Other..."
2. Open up the Android category and select "LogCat"

You can now see the output from System.out.println() and System.err.println(). A nice side effect is that you now can see your Microlog statements as well!

One might ask why should I use Microlog on Android, since there already is a logging API available. This is a perfectly legitimate question. The reason would be that Microlog brings a Log4j like API to the Android platform, but the supplied API is the java.util.logging package. I have always preferred the Log4j API, which was the reason why I choose it for Microlog in the first place. But I guess that you could use Log4j on Android, but Microlog is designed for constrained devices, which Log4j was not.

Microlog Work During the Weekend

During this weekend I finally started my work on the new Microlog V2.0.0. The first thing I did was to implement support for client identification. I did it by adding a property to the Logger that is called clientID. The clientID must be set manually. Since I plan to change the configuration classes, I did not put any effort in adding support for this in existing configuration classes. This will be implemented when I change to to Microproperties.

I have added support for showing the clientID. The SimpleFormatter and ConfigurableFormatter always prints the client ID, if not null. It is possible to use the PatternFormatter as well. You use the %i to print the clientID. It is as simple as that.

The developer have the option of setting the clientID manually or letting Microlog create a unique clientID. I still need to figure out an automatic way of creating a unique clientID. I will have to get back on that.

Microlog the Next Generation

Developing Microlog for the last couple of weeks has been like working with a strait jacket. A lot of the requested features would break the compatibility. Thus I had to postpone these requests and only implement simple features with low priority. On the other hand I wanted the V1.1.0 release to be really stable. This has been very frustrating. Yesterday I decided to release V1.1.0 in order to start my work on Microlog the next generation (V2.0).

The most important new features for Microlog V2.0 are

• Client identification
• New configuration
• Re-send functionality
• Improved packaging
  

The client identification is needed when you have several mobile client logging to the same server. To analyze the logs it is important to be able to identify each client with an unique id. I have not yet decided how the id will be generated. Perhaps the IMEI number? I will have to think about this a little bit more before deciding.

The configuration of Microlog is kind of old fashioned as it is today. Each appender and formatter is responsible for pulling its properties from the properties classes. A much more modern way ought to be dependency injection. Another problem today is that you have a dependency to the MIDlet class. One must remember that Microlog is possible to run in any CLDC environment, not just with the MIDP profile. In such situations it not possible use the properties classes that is used today, but you have to do the setup programatically. I plan to use the Microproperties classes as the default configuration option. However it should be possible to use any dependency injection framework like fallme.

All appenders that log to a server has no recovery function. Let us assume that a MIDlet logs and then crashes. When the MIDlet starts again it should try to re-send the log to the server. Another scenario is that the connection to the server is lost. The logging should continue and try to re-send when the connection is established again. It is all about making remote logging more robust.

Improved packaging is actually not a new feature, but I think it is an important thing to implement. The packaging of Microlog is a little bit confusing. There are many sub projects within Microlog, each with its own deliverable. My guess is that this could confuse any new user of Microlog.

Of course this list is subject to changes, but these are the main ideas as of today. This will give you some idea what is in store for you. Stay tuned for more information about the development of Microlog the next generation. Meantime you could download the all new fresh version of Microlog.

Microlog Feature on the Mobile & Embedded Community and SourceForge

The news that we have released V1.1.1 of Microlog has not gone by without notice. First of all, the Microlog news submission at SourceForge was selected to be headline news on the SourceForge site. This is nice since only a fraction of all project news gets selected for the front page. Secondly Microlog got a project spotlight at the Mobile & Embedded community.

I am honored that we got selected at both these places. Let us hope that this will make the Microlog community even bigger, since this will benefit all users of Microlog.

Microlog with Global Log Levels

This is the first day in ages that I have been able to work with Microlog. It is very nice to be back again and do some development.

There has been several users that have asked for a global log level in Microlog. My initial thought was that this is hard to do, if we should not implement a logging hierarchy. I would like to avoid logging hierarchies, since I think that this would make the Microlog core to complicated and big. Anyway I found a solution to add a global log level to the existing Microlog version, without implementing a logger hierarchy.

The solution is rather simple. You have a method called setGlobalLogLevel() in the Logger class. This is used for all Logger instances, except for those who override it. We have added the method getEffectiveLevel() to check the effective level for each Logger. This method is also found in Log4j, but in that case is has another semantic meaning. In Microlog we have a global level and an individual level, whereas in Log4j it is the hierarchy of Logger objects that decide the effective level.

The setup in the properties file looks like this:

microlog.level=DEBUG
microlog.level.net.sf.microlog.example.PropertiesConfigMidlet=TRACE

The first line is used for setting the global log level. This is similar to how it was before. The new ability is used on the 2nd line, where the log level is set for a particular class.

I hope that this solution would suffice for most users. The next step is probably to introduce a hierachy of loggers. Since this will break the compability, this will be introduced in Microlog 2.0. But we have not still decided whether or not we will introduce a Logger hierarchy. What do you think?

Formatting Your Log in Microlog

When adding logging to your application, it is important that you log the right information. Otherwise you have no use of your log when examining it afterwards. In Microlog you have the possibility to format the logging output. The formatting is not formatting the log message, but rather you add information like the time when the logging was done.

The formatting in Microlog is done using a an instance of a Formatter. There are three formatters available out-of-the-box when downloading Microlog:

• SimpleFormatter
• ConfigurableFormatter
• PatternFormatter

The SimpleFormatter is the default formatter for Microlog. Is is the smallest and fastest formatter. It prints the time, the level, the message and the Throwable object if there is one available. This is always a good starting point when using Microlog for the first time. You could set the formatter in code like this:

ConsoleAppender appender = new ConsoleAppender();
SimpleFormatter formatter = new SimpleFormatter();
appender.setFormatter(formatter);

The final string looks like this:

494:[INFO]-Starting app


The ConfigurableFormatter gives you a little bit more control of the formatting. The order is pre-defined, but you get to choose what to log. You get to choose if you want to log the level, message and the name of the logger. You could set the time format and specify which delimiter that is used between each printed field. If you choose to print the time as date it looks like this:

2009-02-10 19:38:00.188:[INFO]:Starting app

The available properties are:

• PrintName - Set to true if you wish to print the name of the Logger instance.
• PrintLevel - Set to true if you wish to print the current Level.
• TimeFormat - Specifies which time format to use. The possible values are: NO_TIME, DATE_TO_STRING and TIME_IN_MILLIS. The DATE_TO_STRING uses the toString() of the current Date object (now). The TIME_IN_MILLIS writes the time in milliseconds.
• PrintMessage - Set to true if you wish to print the logged message.
• Delimiter - Set the delimiter to separate each printed part. Use a String of your choice.
  

The PatternFormatter is the Formatter with the most opportunities. It works by defining your own formatting pattern. The pattern could be set in your code or by a property in a properties file. For example it could look like this in your property file:

microlog.formatter=net.sf.microlog.format.PatternFormatter
microlog.formatter.PatternFormatter.pattern=%d [%P] %m %T

The formatted string look like this:
15:38:49,199 [INFO] Starting app

The available formatting options are:

• %c - prints the name of the Logger
• %d - prints the date (absolute time)
• %m - prints the logged message
• %P -prints the priority, i.e. Level of the message.
• %r - prints the relative time of the logging. (The first logging is done at time 0.)
• %t - prints the thread name.
• %T - prints the Throwable object.
• %% - prints the '%' sign.

If you are not satisfied with the supplied Formatter implementations, you could create your own Formatter. This is done by creating a class that implements the Formatter interface. The interface looks like this:

public interface Formatter {

/**
* Format the given message and the Throwable object.
*
* @param name
*            the name of the logger.
* @param time
*            the time since the first logging has done (in milliseconds).
* @param level
*            the logging level
* @param message
*            the message
* @param t
*            the exception.
* @return a String that is not null.
*/
String format(String name, long time, Level level, Object message,
Throwable t);

/**
* Configure the appender.
*
* @param properties
*            Properties to configure with
*/
void configure(PropertiesGetter properties);
}

The format() method is where the actual formatting is done. It creates a String object that is the actual String that is logged. Nothing more, nothing less. The configure() method is used for configuration of the Formatter. The PropertiesGetter object is used for fetching the properties that the Formatter is interested in. Thus you could define your own properties that you use for your Formatter implementation.

I hope that you have learned how to master the art of formatting in Microlog by reading this. If you still have any questions about this, please use the official Microlog forums to find your answers.