LogSaw Project

LogSaw – a high-performance log viewer based on Eclipse

Because of a rather nasty bug, here comes another update!

Changes in this release:
Fixed NullPointerException when synchronizing log resources that have no timestamp field (ID: 3485287). Please note: In such a case, the log resource is now automatically truncated before each synchronize to avoid duplicates.

The auto-truncate will also be performed in case a timestamp field does exist, but with no date component (i.e. HH:mm:ss).

The long overdue release 1.0.2 is out now! It brings some bugfixes and improvements, most notably:
- When adding a new log resource, patterns are remembered and can be re-used (use CTRL+Space in the pattern text field)
- New JBoss 7 log dialect
- Fixed bugs when pattern did not contain timestamp
- Updated Eclipse runtime to 3.7 and Lucene to 3.5

As usual, you can get it from SourceForge.net or via the built-in update function.

As for updates: There have been a whole lot of changes since the 1.0.1. Though, most of them were somehow related to the Git move or some infrastructure changes (Eclipse updates, Lucene updates etc.), so there is no real benefit for the user.

The only real changes that come to my mind right now are: support for JBoss AS 7 and a minor bugfix related to pagination. But since the last release is getting quite old now, I’m looking forward to release a minor update within the next few weeks.

First of all, sorry for the slow updates! I’ve been quite busy lately, and LogSaw already does pretty much all I need, so the pressure for me to make changes has been quite low. Though, it’s still all alive and development should continue soon :-)

I have been playing around with Buckminster some more recently, and I ended up making the whole development process alot easier (did I already mention, that I really like Bucky?). So, if you ever wanted to play around with the LogSaw source yourself, but were unsure on how to get started: The new Building LogSaw tutorial should help you to get started.

I have just completed moving the source code to Git SCM. The master repository is now hosted on GitHub. However, a clone of it is also hosted on SourceForge because it doesn’t allow to point to an external Git repo only.

Then again, Git is very capable in terms of syncing multiple repos so this shouldn’t be much of an issue :-)

So 2010 is almost over and I feel it’s time to share some of the plans I have for this humble project for next year:

  • Move to Git
    I’m not sure whether it is because of SourceForge being so slow or because of Subversion itself, but working with the SVN repository seems terribly painful. With all the cool kids moving to Git, it’s probably time to follow suit.
  • Put out one or more Feature Releases (1.1, …)
    Some feature requests have already been posted in the tracker and some of them should better be implemented sooner than later.
  • Put out Framework Release (2.0?)
    I have often stated that I envision LogSaw as a framework that everyone and his dog can build upon to parse and analyze arbitrary log files or even other data. This will require a major re-engineering effort so it will definitely take some time. But on the other hand, it’s definitely a challenge I’m looking forward to :-)

Hot on the heels of 1.0.0 comes the first bugfix release. It’s primarily intended to fix problems on Linux. But to make it a worthwhile upgrade, I have also merged some of the changes from the 1.1 stream: most notably, you won’t need to close a log viewer anymore in order to see new entries after synchronizing the log resource.

As usual, you can get it from SourceForge.net or via the built-in update function.

Yesterday, I learned that OSGi Declarative Services (DS) and Blueprint Services (BS) are two different things. That was truly a D’Oh moment.

In DS, you create one component.xml file for each Service you want to share, which outlines the references to other services among other things. Overall this seems to be a nice alternative to writing bundle activators, but nothing earth shattering. On the bright side, DS is supported by Equinox for some time already, given you have the org.eclipse.equinox.ds bundle in your target platform.

Now with BS, things get more interesting. It’s basically the Spring way of doing things applied to the OSGi world. The XML configuration files of BS look very familiar when you have past experience with Spring-powered J2EE apps. You can define all the Services your bundle provides in one XML file, wire them up with other services and so on.
continue reading…

After having sorted out the p2 problems, the final release is now available for download on SourceForge.net. Alternatively, simply start LogSaw 1.0.0 RC1 and the final bits will be offered to you via the built-in update function.

P2 update should work now, after I have changed the product configuration to follow a standard layout that is recommended by the Buckminster folks.

RCP Product configuration best practice

The configuration is depicted in the diagram shown above. For building, we first import site.feature. This feature in turn includes the product.feature and buckminster.cspex that will contribute the create.product and create.product.zip Buckminster actions.
continue reading…