Alan's RamblingsJava

mod-rewrite equivalent for Tomcat

Wed, 02 Jun 2010 17:15:00 GMT

I've migrated and merged my old blogs.sun.com and bleaklow.com blogs into this new one, using Pebble. As a result, there are a number of links out there on the interwebs to bleaklow.com that are now broken, as everything has moved around - google's webmaster tools gives me a comprehensive list. If I was hosting this blog using Apache, the standard solution would be to use the most excellent mod-rewrite Apache module to redirect the broken links to somewhere appropriate. However Pebble is a J2EE application and uses Tomcat instead of Apache. I've been looking for an equivalent to mod-rewrite for a while and never managed to find anything. Whilst looking for something else entirely (always the way) I found Url Rewrite Filter. This is functional equivalent to mod-rewrite for J2EE servers, and offers most of the same features as mod-rewrite. I'm using it and it seems to do the job just fine, and the beta even has a mod-rewrite style configuration option, if you need a security blanket :-)

Simple parser for MovableType exports

Sun, 23 May 2010 10:03:00 GMT

As part of moving my blog over to I needed to be able to transfer the content from my old MovableType blog and my blogs.sun.com blog, which runs on Roller. Both MT and Roller can export in MovableType export format and Pebble has a MT importer, so it looked relatively straightforward. However when I looked at the content I was importing it was clear I'd need to munge it on its way into Pebble. The Pebble MT importer is one-pass and loads the entries into Pebble as it reads them, whereas I wanted to read them in, munge them and only then load them into Pebble, so I wrote a simple parser to read in the MT export. It's not a thing of great beauty but it got the job done. I thought it might be useful for other people who want to read MovableType exports from Java, so I've put a copy of it here.

Image thumbnailer for Pebble

Sun, 23 May 2010 08:54:00 GMT

This blog uses the Pebble package for delivering content. Pebble isn't a particularly common blogging package but it fits my purely personal and subjective requirements:

Not written in PHP (blegh)
Open source, and something in Java would be nice
Doesn't use a database and uses flat files that I can manage manually if I need to
Good RSS, search, tag and category management
Can be restyled easily

The old incarnation of this blog used MovableType but that doesn't really tick the Open Source box any more. blogs.sun.com uses Roller but that requires a database back-end. All these constraints combined to give a pretty short list of candidates, i.e. Pebble.

One thing that Pebble lacks is an image thumbnailer. I'm not bothered about glossy JavaScript solutions such as Lightbox, and I'm quite happy to type in HTML table definitions. All I wanted was something to save me the tedium of manually generating the thumbnails and typing in the HTML to display them and link to the full-size image in a popup window. MovableType has this feature but Pebble doesn't so I sat down one evening and knocked together an equivalent as a Pebble plugin, using the standard Java2D APIs to do the image manipulation. All the thumbnails on this site are done with it, and I've submitted this as a patch to Pebble so hopefully it will make it into a future release.

Update

The patch has been accepted and should be appearing in a future version of Pebble.

Why I hate XML configuration files

Thu, 05 Apr 2007 14:38:44 GMT

I'm working on a reasonably large (1000+ source files) J2EE application that makes extensive (some might say utterly excessive) use of external components - it requires in the order of 50 JAR libraries to run, over and above the standard J2EE ones.

And of course many of those JAR files have their own unique XML files to configure them.

And of course many bits information related to the configuration of the application (URLs, database details etc) have to be repeated in more than one of those XML files.

And there's no global way of doing this.

So the people who originally wrote the application came up with a scheme - they'd store the configuration values in property files.

But that only helped for things that got the values dynamically, for example by using the J2SE Properties class. All those external components they'd used didn't know anything about the application's property files, they only knew about their own unique little XML files.

So the people writing the application came up with another scheme - they'd embed tokens in all those little XML files, then use the Ant Filter task to replace them at build-time with the values from the property files.

"Job's a good 'un!" they doubtless exclaimed, flushed with their extreme cleverness.

Then I came along and had to maintain the beast, when I found:

There are in excess of 50 of these properties, which makes configuring the application more than a little tedious and more than a little error-prone.
The names of the tokens processed by the Ant Filter task and the names of the properties used to set their values mostly bear very little relationship to each other.
There is no consistently-applied property naming scheme. There are in fact several inconsistently-applied naming schemes.
Some of the properties are just renamed versions of other properties. Sometimes they are inconsistently renamed versions of other properties. Sometimes they don't appear to be used at all.
It isn't clear when reading a property file which properties are only used at compile time by the Ant Filter task, and which properties are only used at run time. It's also unclear which ones are used at both compile and run time.
The compile-time use of properties is a killer because it means the application can't realistically be reconfigured without recompiling it - because the use of the Ant Filter task means the compile-time property file values end up hard-coded in many different places. It's therefore pretty much impossible to produce a version of the application that can be deployed on more than one machine - for example for development or test purposes.

All this means that there's a whole series of bear traps set for anyone who innocently changes any of the properties files of the application, in the mistaken assumption that the application will actually take any notice of them.

I'm sure I'm not the only person to have been hit by this problem - how to configure multiple external components which all have their own XML configuration files - without having to hand-edit each of the XML files each time every time something changes, and without hard-coding the configuration at build time. However I'm damned if I know of a good way of doing it - although I can easily think up several not-very-good ways of doing it.

If you know, please let me know!

Hosting a community website using Solaris and Tomcat

Mon, 27 Nov 2006 02:54:59 GMT

Outside of work I'm also a member of a Community-based Samba band, Meninos do Morumbi Oldham, along with my son James. Like most people in the IT business, once people figure out what you do you inevitably get requests to help with anything related to computers, and I got collared to set up a website for the group. I started looking around for hosting providers, and my original choice was bluehost.com, based on the recommendation of my colleague Phil. However, the membership management application I'm also developing is written in Java, which mean I really wanted to run Tomcat on the site as well, and bluehost didn't offer that option. Finding a hosting provider who would host Tomcat at a reasonable price proved incredibly difficult - the costs were way more than a non-profit like us could afford. Eventually I stumbled across mod3, a UK-based hosting provider who offer a Solaris 10 zone for the princely sum of £9.95 per year, plus pay-as-you-go for network bandwidth, disk space etc. The fact that they were running Solaris appealed to me, and I was happy to risk the £10 involved out of my own capacious pocket ;-) The base hosting package also came with 660Mb of usable disk space, which was plenty for our needs.

After purchasing the site domain name and hosting I started to think about what I wanted to put on the site. You get 64Mb of RSS memory with a base zone config, which meant I needed to be fairly careful with what I ran on the site. As I said, I knew I'd probably want use Tomcat at some point, so I began to wonder if I could run the whole thing with Tomcat alone. From previous experience of setting up similar websites before, I know that setting up the site is relatively easy, the real problem is providing content, then keeping it up-to-date and relevant. I also didn't want to become the bottleneck for making changes to she site, which pretty much meant that I needed to use some sort of Content Management System, so that I could give other members of the group the ability to edit content. Nearly everyone in the organisation is a non-IT type (one of the attractions of the group for me ;-), so whatever I used had to make editing easy - requiring that people hack on raw HTML was a non-starter.

As part of the day job I'm looking at the possibility of using a CMS for part of the OpenSolaris website, so I'd already been looking around at what was available (and free!). I didn't need an 'Enterprise level' CMS - features such as versioning, content staging, multilingual support or workflow management weren't necessary, what I needed was something easy for users to understand, and that didn't have huge resource requirements. And being written in Java was a bonus, as it meant I could then run it under the Tomcat instance I already knew I was going to need for the membership management stuff.

My final choice was MeshCMS, and I've been extremely happy with it. It hit all the key requirements that I had - simple to deploy (single WAR file, no database required), easy to customise, structures the site using the directory/subdirectory paradigm that any PC user is already familiar with, has an integrated WYSIWYG editor for editing content, and the clincher - has very modest resource requirements and fits inside my 64Mb RSS constraint. MeshCMS has been exceedingly well thought out - designing the look and feel of the site involves just modifying a single JSP template, which is then applied to all the pages. The site navigation menus are all automatically generated from the layout of the directory hierarchy used to store the page content, and most-frequently accessed pages bubble to the top of the menus. Linking to other pages in the site is easy - the integrated editor provides a dynamically-generated list of pages that you can select from. The editor even provides a list of the styles defined in the site stylesheet for you to select from - a feature that Roller (the package used to run blogs.sun.com) could well do with emulating.

Having decided on the CMS, the next task was to see if I could minimise Tomcat's footprint as far as possible. Tomcat runs as a normal Unix process, and so doesn't have permission to open low-numbered ports (below 1024), which is why by default it runs on port 8080. Webservers normally run on port 80, and using that port requires root privilege. The Apache webserver gets around this problem by starting up as root, opening port 80 then switching user to the webserver user before starting to serve pages. However Tomcat is written in Java, so Unix-centric mechanisms like switching user aren't an option. The normal way to get around this is to put Tomcat behind Apache, using the mod_jk module to shunt traffic between the two. However because of my memory constraints, I wanted to avoid using Apache if at all possible. There are a number of fairly vile hacks for doing this for Linux, including stuff such as firewall or userland port redirection, but most of them suffer from various problems.

However because I was running on Solaris, I had a far better option. I was already intending to run Tomcat as a SMF service, and one of the lesser-known features of SMF is that it is integrated with the Least Privilege mechanism in Solaris 10, which allows you to grant elevated privileges to normal user processes in a controlled way. This meant that allowing Tomcat to open port 80 simply required granting it the net_privaddr privilege:

    <method_credential user='meninos' group='staff' privileges='basic,net_privaddr' />

The really neat thing is that I didn't have to give the meninos user the net_privaddr privilege permanently, it only needs it for the duration of the service start method.

So, if you are ever in the Greater Manchester area, check out our performances page on the website and if you get a chance, pop by and hear us play ;-) We were out busking in Manchester yesterday, and for once the weather was kind, despite the time of year :-)