As a programmer, most of us would have been taught to write comments, externalize constants, indent code and of course log the flow of control. Credit goes to OpenSource for having provided such wonderful frameworks like Log4j to enable logging.

The framework authors did foresee the problem of growing log files and were smart to provide means to control the level of logging. While, this does help a lot to categorize log entries, it doesnot solve the most commonly occurring problem for a developer:

That of “Spotting the log entry” that is most relevant to the situation.

Let me explain. Picture this: a large application has been deployed in production for a while. The log level has been set to INFO because the application support team argues that ERROR doesnot give them enough detail for trouble shooting. In the application code, a few developers have gotten carried away and have logged entry and exit of each method call (re-inventing the “around” advice in AOP if you may call it that way). The result – log files that have rolled many times over and totalling to around 100 MB across just as many files.

These files are not always easily available to the developer debugging a problem that has been reported in production. The developer needs to quickly find the log entry that helps to diagnoze the issue and here the “Spot the log entry” contest begins.

Obstacles in this course are(and not limited to) :

  • Having to sift through potentially hundreds of thousands of log entries
  • Log files located on remote machines accessible via protocols like SSH/SFTP.
  • Noise in log files – entries that log entry and exit from methods
  • Absence of tools to analyze the structured data contained in log entries. Text editors are an often used, but poor choice.
  • Inability to analyze contiguous log events. For e.g log entries made from one thread donot appear together in a log file in medium to heavy use systems.

There are a few ways in which this problem can be addressed:

  • Avoid AOP like log statements in code. Use AOP at run time to instrument byte-code on the fly if required.
  • Clear logging strategy
    • Log errors when encountered the first time and not when it is handled each time, say as it progresses up the call stack.
    • Use of appropriate log levels to differentiate between debug information, messages, warnings and errors.
    • Use of log patterns that provide sufficient information to analyze the flow. Logging timestamp, thread, category and priority for e.g

What if your log files are still huge after all this? Its time to invest in tools that help you spot your log entry.

Some of us at MindTree( looked around for OpenSource tools for log analysis when we had to inspect logs from aorund a dozen servers. Chainsaw ( was a decent implementation but not good enough. Commercial tools were not satisfactory either.

Thats when we decided to implement Insight – an application analysis tool.


To start with, it was conceived to do comprehensive log analysis. In brief it provides the following:

  1. Provide visual analysis of any pattern based log files
  2. Analyze logs from remote servers over (S)Ftp and Http.
  3. Supports tailing of local files and a plug-in for Eclipse
  4. Provides summary and detailed view of the log event
  5. Supports “no-mutating” analysis of the data set – such as search, sort.
  6. Supports “mutating” analysis of data set – via progressive filtering
  7. Helps to locate the “context” of an event i.e snap shot of log entries around a specific log entry.
  8. Optimized for performance and footprint size
    1. Loads 1000 entries in around 375 ms
    2. VM size between 45 to 60MB even after loading 110 000 entries

See attached presentation for details on Insight and testimonials : Insight features

Our developers are now front runners in the “Spot the log entry” contest 🙂


MindTree Insight is now an OpenSource project on SourceForge and is available at :

The download of the latest release is available at:


I have seen enough content on the net to create a web application that supports asian languages input and display.

You can find a good article here :

On the other hand, I couldnot find comprehensive example on achieving the same using rich clients such as a Swing application.

Some help from the internet and effort later, I was successful at writing a Swing application to display Japanese characters read from a .properties file. Some learnings from this exercise are:

  • First and foremost, you need to install fonts that support the language you are trying to use. For e.g you need a Japanese font if you intend to run the application on a English version of Windows. You can download one(MS Mincho) from :
  • On Windows, this needs to be installed under the /windows/fonts folder.
  • The font is the only thing that needs to be installed on your client machine to run the application. Using the font is lots easier in Swing unlike in AWT. For AWT components i.e one that has a native peer, you need to customize the settings of the JRE i.e modify under /jre/lib to include the font you have installed under each font type. I have intentionally not provided the details as it applies to AWT and not Swing, the subject of this post.
  • Now in your Swing application, you just need to set the font of the Swing component before setting its text.
  • Now forthe source of the text. It can come from a text file such as a .properties file. Note here though that the file must contain the content in ascii form and not in unicode form. You may use the native2ascii tool that comes with Java 2 SDK to achieve the conversion.

I have attached a sample Swing application that displays Japanese text from a .properties file. It is available as Editor.doc (rename to

You also need the .properties file. It is available as messagesbundle_ja_jp.doc (rename to

Copy both files to a single folder. You can then run the application as:

javac -classpath .

java -classpath . Editor ja JP

You will then be able to see the application as shown below:

Japanese Swing app