A new stable build of RvSnoop is available for downloading (it was actually released back on the 12th, but I forgot to post about it here and have been away from the internet for a few days). New in this release:

• Added an option to republish records to different connections.
• Added actions to export and import records to a binary file format (the records are stored in a ZIP based file, they are stored as wire format messages with some additional metadata).
• Added an action to remove connections from the list; also, added some options to the connection list context menu to access the recent connections list.
• Added a dialog to allow the user to configure different record types. The underlying code to support this was present in the 1.5 release, but there was no way to access it short of editing the saved project file by hand.
• The build system no longer strips out unused classes from the included libraries. This increases the size of the download but in some cases the licenses of included libraries require this, and it simplifies the build process, which is a Good Thing.
• Started to use the Commons Lang and Commons IO libraries from Apache instead of the utility classes that I had written myself. The next step is to start using Commons Logging instead of my own custom logger.

Just in time for Christmas, Tom Copeland has announced a new release of PMD with some notable speed increases. Hopefully this will make it fast enough to use the Eclipse plug-in in regular development, rather than having a separate ‘analysis’ phase to clean up any warts before each release.

Now that the 1.6 release of RvSnoop is out of the door (OK, 1.6.1 ‘cause of a wart inthe original release), there are certain features that I’d like to see added, and for the 2.0 release I want to have in place a foundation that will make it easier to add these.

A full list of features can be found in the plan file in the RvSnoop Subversion repository, but some of the big ones that will impact the overall architecture of RvSnoop are…

Pluggable Persistence Mechanism

I’m going to migrate the record ledger to being persistent, there are a couple of options here as to how this will be handled: flat files, a combination of flat files and Lucene based indexes, or some kind of JDBC backed store.

One option would be to make the persistence mechanism plug-able, this would also ease the use of an all-in-memory storage system, like the one that is currently used (which is useful when you just want to use RvSnoop as a graphical replacement for tibrvlisten).

Able to Run Headless

I’d like to add the ability to run RvSnoop without the UI, this would be based on loading a pre-configured project. Combining this feature with a JDBC backed store this could be really useful for auditing and logging messages.

EMS Support

I registered the emssnoop.org domain at the same time as rvsnoop.org, and there has been a project on SourceForge for a while, even if it hasn’t had anything checked in to it yet! An open question is whether to try for generic JMS support or just work with EMS directly.

User Written Plug-ins

It would be nice to be able to cleanly extend RvSnoop if required, without going back and modifying the main code base.

So, What About 2.0?

All (well, most) of these features point to a need for an extensible plug-in system, Eclipse has shown that a good way of architecting a desktop application (or any application, for that matter) is to build it entirely from plug-ins wrapped around a small core.

So, the upshot of this is that I’m planning on migrating to a managed runtime, probably OSGi, for the 2.0 release. I’ll talk about this more in another post. In particular, what’s the cost/benefit ratio of using this type of runtime; and which runtimes are good?

There are a number of cases in Java where I find myself wanting to use a variant of the factory method pattern. For example:

• To control the number of objects created, or to create a limited set of objects (one per value of an enumeration for example, this could use an backed map in J2SE 5);

• To perform some checks before creating object. Like init() called before instantiating instead of after.

Often my instinct here is to add some static methods to the class and make the constructors private. I think that in part this comes from the pattern name: factory method, I think a better name would have been factory class, or maybe just factory. Anyway, doing this has some advantages in that it reduces the number of classes that need writing and keeps all of the code in one place. Like this:

But there are drawbacks as well. The main one being that I cannot then treat the factory like a bean, this makes it more difficult to display in UI (by preventing the use of common binding frameworks for example). So a better approach is more like this:

Note that this is still one class short of the pattern described in the Wikipedia article. The Creator interface is just unnecessary as far as I’m concerned (although there is a case for it’s existence in scenarios like the various Java SPI-style interfaces).

A new development build of RvSnoop is available for downloading. This release contains all of the features that will be in the finished 1.6 release, due out sometime next week.

Changes from the last development build include:

• Added support for republishing on different connections.
• Added column to ledger to display wire size of messages.
• Fixed bug that caused republished messages to be filtered incorrectly from the subject hierarchy.
• Fixed bug with ledger renderer which caused striping to break when columns were added/removed from the view.
• Minor code clean-ups and removal of a couple of unused methods.
• Updated the FAQs page with correct details of timestamp formatting in ledger (this hasn’t been pushed out to the public site yet).

The only things left to do now (assuming no new bugs are found) are some additional testing and documentation updates.

A new development version of RvSnoop is now available for download. This version adds:

• Saving and restoring messages between sessions.
• Remove Connection as a context sensitive menu option.
• Improved drag and drop support.

And also fixes some bugs involving the screen menu on Mac OS X. The save and restore messages option writes the selected records from the ledger to a ZIP based binary file format (it’s the same format that is used internally by the copy and paste mechanism). The format has also been enhanced to include subject information for the messages, as this is stripped out by the raw Rendezvous library calls.

Apparently (according to this) Mac Office is 30,000,000 lines of code, that’s a lot of code to try to keep bug free! Out of curiosity, I downloaded a utility to count lines of code and found that RvSnoop is only ~7,000 lines of code. That’s only counting non-comment lines, I don’t know how well commented the MS codebase is.

Not that there’s any real comparison in functionality between the two of course!

The latest version of iTunes has made several changes to the UI (again), most of them not for the better as can be read about here.

Still, at least one of the annoyances, the use of all capitals for section headings in the source list, can be easily corrected. The section headings are stored as localizable strings in a resource file; so first shut down iTunes, then just open the /Applications/iTunes.app/Contents/Resources/English.lproj/Localizable.strings in a text editor (e.g. TextMate) and search for the following lines:

1
2
3
4

"135.011" = "LIBRARY";
"135.012" = "DEVICES";
"135.013" = "STORE";
"135.014" = "PLAYLISTS";

these need changing to:

1
2
3
4

"135.011" = "Library";
"135.012" = "Devices";
"135.013" = "Store";
"135.014" = "Playlists";

or anything else that you like. Now when you restart iTunes it should all look better.

Update: You also want to change this line: "135.006" = "SHARED"; to this: "135.006" = "Shared";

A new version of 1060 NetKernel was released today, version 3.1. I had a brief play around with the previous release but never really had the time to dig into it too deeply. It always looked pretty neat though, a possible good solution to base adapter (in the TIBCO sense) style components on. One of the advertised features of the new release is a newly written ‘Getting Started Guide’, so this may be a good opportunity to have another look.

For RvSnoop I’m currently working on adding namespaces to all of the files that are used to save the application preferences and also the project files. This is a Good Thing in and of itself, as it allows me to use XML Schema to validate and document the files formats. But, more importantly, it gives me the opportunity to refactor as I go alond, the general plan is to make the projects in the next release be based on directories rather than a single XML file, this will allow me to use a disk based storage mechanism for messages so that they will be persistent across sessions.

Playing Well With Others

At the same time, I’ve taken the opportunity to include some of the Apache Commons libraries in the build. There were (well, still are) a number of small utility classes scattered around which I’m planning on replacing with the versions from Apache.

One side effect of this is that the build is increasing in size, to help control this I’m going to remove the Berkeley DB dependency from the build. I was origiannly planning to use this for the on disk message store but I’ve changed my mind here. My current thinking is to just write the messages out to files but to have a set of indexes (probably built using Lucene) as well for searching and sorting.

There should be another (alpha) release out later this week with the Commons and Berkeley DB changes complete, and a release next week with the new project structure.