Feb 28, 2009

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.

5 comments:

Marcos Maia said...

Hi,

Great work. I was very glad when in my first JME project I felt the necessity to use some log api and could find MicroLog. Today I'm starting implementing it in my project. Tx for this great work. I'll let you know my impressions soon.

regards.

P.S - I'm still stuck with wich JME DB to use? With your great experience, do u have suggestions on it?

My Open Source Software Development Blog said...

Hi,

thanks for for your nice words.

When you are talking about JME DB, do you mean a DB on the device or do you refer to a DB that you connect your device to?

Regards
Johan

Marcos Maia said...

Hi,

What I need is a JME DB. You'll find details on this post at javaranch forums: http://www.coderanch.com/t/434448/Java-Micro-Edition/Mobile/JME-portable-free-database
I also started implementing your MicroLog API in my JME project and have some points to consider. Where should I post my considerations so far?

[]s

Marcos Maia.

My Open Source Software Development Blog said...

Aha,I see what you mean. I have not had the opportunity to try out different Java ME databases. RMS has been good enough in my projects. I mostly use ot for storing some application settings and such. Also I prefer to store data on the server. Sorry, I cannot give you an answer on that.

If you have any question and such about Microlog, please use the official Microlog forums:

https://sourceforge.net/forum/forum.php?forum_id=464718

Regards
Johan

Marcos Maia said...

[quote]Also I prefer to store data on the server[/quote]

It's probably the most recommended approach, unfortunately this is not an option for me. I need my app to work and persist consistent data even offline, and RMS seemed to messy to evolute and maintain afterwards.

regards,
[]
Marcos Maia.

P.S - I'll post my questions on MicroLog Forum, tx.