Archive for the ‘ Software ’ Category

The road ahead for SiteMesh 3

Here’s an update of what’s in store for the upcoming SiteMesh releases and how they benefit you.

Firstly, there are a number of accumulated bugs that we’re steadily working our way through. The recent 2.1 and 2.2 releases have been mostly bugfixes, and this will continue for the 2.x series, including those related to using MVC frameworks such as Struts and WebWork.

Meanwhile, SiteMesh 3 has been brewing. It’s been four years since SiteMesh was first open-sourced (it existed for two years before that as closed-source) and in that time it hasn’t really changed significantly. SiteMesh 3 is going to see the largest set of improvements since it was initially released.

h3. Flexible HTML processing

The core of SiteMesh is based around an HTML parser that is very fast and tolerant to badly formed HTML, however at the cost of being extremely hard to extend.

SiteMesh 3 will contain a new parser, which is easy to customize, without compromising on performance and tolerance to malformed HTML. This will allow extensions to be written that can:

* Extract user-defined properties from the page beyond the predefined ones from <title>, <meta>, <content>, etc.
* Remove blocks of content from the page.
* Transform HTML as the page is parsed.

SiteMesh will come bundled with extensions for popular tasks and it will be trivial to add your own. More on this in a follow-up entry.

h3. Improved Velocity integration

This follows on from some work done by Atlassian and will allow a page to be generated using the Velocity API as an alternative to calling Servlet
RequestDispatchers and the Filter.

This offers significant performance improvements for applications that don’t use JSP and allows more of SiteMesh to be used in environments outside of the Servlet container, which leads nicely on to the next feature.

h3. Offline support with StaticMesh

There has been a lot of demand for using SiteMesh to generate web-sites in an offline manner. A common case for this is a simpler alternative to DocBook style tools, allowing documents to be authored in standard HTML capable word-processing tools (such as MS Word, OpenOffice and Mozilla Composer), giving you the full capabilities of a rich-text word-processor and without the need to learn a special markup/schema.

SiteMesh can then process these raw HTML files and generated another set of static HTML files with the appropriate presentation and navigation added.

Building upon the extended HTML processing capabilities, it will also be possible to do things like generate a table of contents, footnotes, and diagrams from inline syntax.

There have been at least three seperate incarnations of StaticMesh appear over the last few years. We hope to bring the best bits from each of these into the final version.

StaticMesh will have a simple API for configuration, bundled with a command-line wrapper and Ant task.

h2. Backwards compatability

Just to ease your minds, you’re not going to have to rewrite your applications to use SiteMesh 3. Great effort will be taken to ensure that backwards compatability is preserved. The library will have more features, but at the same time a lot of the old stuff can be simplified. Dependencies will be minimized and optional – for example, you will only need velocity.jar if you’re actually using the Velocity stuff.

I’ll be posting more information later.

Watch this space…

SiteMesh 2.2 Released

I’ve just released SiteMesh 2.2 This release fixes a number of minor bugs. No code changes are required if migrating from 2.1.

The following improvements have been made:

* The <excludes> tag in decorators.xml now takes into account ServletPath, PathInfo and QueryString.
* Overhaul of the main Servlet Filter to remove unnecessary complexity and more gracefully handle situations where the order of calls on the ServletResponse, PrintWriter and ServletOutputStream occur in an awkward order.


* Sitemesh
* Release notes and changes
* Download

Stay tuned for news on the cool new features coming up SiteMesh 3!…

Advanced SiteMesh

Sunil Patil has written an article about SiteMesh for

Read Advanced SiteMesh.

REST and FishEye

The latest version of FishEye now has a REST API (oh and an XML-RPC API too, which is less interesting).

I’m happy partly because FishEye is a great tool and this will allow integration with other tools – things we are seeing more and more with its natural friends like JIRA, DamageControl and Confluence.

But what I’m really glad to see is that they made the decision to go with REST rather than just stick with the usual suspects SOAP or XML-RPC. Looking at the actual API for FishEye, REST seems like a no-brainer as all of the calls are queries.

On the last system I worked on, we were struggling with SOAP and switched to a simpler REST approach. It had a number of benefits.

Firstly, it simplified things greatly. With REST there was no need for complicated SOAP libraries on either the client or server, just use a plain HTTP call. This reduced coupling and brittleness. We had previously lost hours (possibly days) tracing problems through libraries that were outside of our control.

Secondly, it improved scalability. Though this was not the reason we moved, it was a nice side-effect. The web-server, client HTTP library and any HTTP proxy in-between understood things like the difference between GET and POST and when a resource has not been modified so they can offer effective caching – greatly reducing the amount of traffic. This is why REST is a more scalable solution than XML-RPC or SOAP over HTTP.

Thirdly, it reduced the payload over the wire. No need for SOAP envelope wrappers and it gave us the flexibility to use formats other than XML for the actual resource data. For instance a resource containing the body of an unformatted news headline is simpler to express as plain text and a table of numbers is more concise (and readable) as CSV.

REST is something I hadn’t really considered until recently and is by no means a golden-hammer, but in our case it worked out better than SOAP and XML-RPC.

The power of closures in C# 2.0

Martin Fowler (obligitary Fowlbot namedrop) recently blogged about the power of closures in languages that support them. It’s worth remembering that C# 2.0 has true closure support in the form of anonymous delegates. This includes reading and modifying variables outside the context of the closure – unlike Java’s anonymous inner classes.

Just for kicks, I’ve rewritten all of the examples Martin’s Ruby examples in C# 2.0. This makes use of the improved APIs in .NET 2.0 pointed out by Zohar.

Ruby C# 2.0
def managers(emps)
return {|e| e.isManager}
public List<Employee> Managers(List<Employee> emps) {
return emps.FindAll(delegate(Employee e) {
return e.IsManager;
def highPaid(emps)
threshold = 150
return {|e| e.salary > threshold}
public List<Employee> HighPaid(List<Employee> emps) {
int threshold = 150;
return emps.FindAll(delegate(Employee e) {
return e.Salary > threshold;
def paidMore(amount)
return {|e| e.salary > amount}
public Predicate<Employee> PaidMore(int amount) {
return delegate(Employee e) {
return e.Salary > amount;
highPaid = paidMore(150)
john =
john.salary = 200
Predicate<Employee> highPaid = PaidMore(150);
Employee john = new Employee();
john.Salary = 200;

The code difference between the languages isn’t that difference. The C# 2.0 code is obviously longer (though not a lot) because:

  • C# 2.0 is staticly typed (let’s not get started on the static vs dynamic debate).
  • C# 2.0 requires the ‘delegate’ keyword.
  • Ruby allows you to ignore the ‘return’ keyword.

You can try this stuff out yourself by playing with Visual C# Express.

NMock article in MSDN Magazine

An article about NMock has appeared in the October issue of MSDN Magazine. Chuffed :)

Mock Objects to the Rescue! Test Your .NET Code with NMock

XStream article on O’Reilly

A simple way to access JavaDoc attributes at runtime

It’s easy to gain access to JavaDoc attributes using QDox, however this requires you to have the source available. At runtime this isn’t always possible, unless you’re happy giving your source away.

A workaround to this is to use QDox to parse the source code at development time and serialize the resulting structures to make them available at runtime. This will work, but it’s a bit nasty as big binary files aren’t the most stable of things.

A more open approach is to bundle the source of your classes with the application, making them available at runtime, however *without* the method body implementations.

*Class with method body implementations:*

package stuff;

public class CheeseSlicer {

/** @transaction mode=isolated */
public Slice feedMe() {
// some implementation specific stuff here.. don't waste your time reading it.
if (System.currentTimeMillisMillis() % 2 == 0) {
return new CheddarSlice();
} else {
return new BrieSlice();


*Class WITHOUT method body implementations:*

package stuff;

public class CheeseSlicer {

/** @transaction mode=isolated */
public Slice feedMe();


To do this is simple. First, QDox can be used to parse the source of a class into a JavaClass. Calling JavaClass.toString() will print out the class without the body implementations (as above). This is something done at development time and the result should be written to a file that is available at runtime.

At runtime, QDox can read this file just as if it were a full-blown Java source file, making the attributes available.

JDK 1.5, of course, makes this redundant, but in the mean time…

XStream roadmap: What do YOU want to see?

I’m assessing where the next version of XStream should go. There are three major chunks of work I’d like to tackle (described below), however I can only take on one at a time and need to prioritize.

What do you want to see? Leave your comments on my blog.

1. Full support for the Java serialization specification.

Current situation: XStream uses reflection to access an objects fields and convert them to and from XML.

Problem: While this works well with most custom objects, there are many classes (particularly in the standard java and javax packages) that rely on advanced features of the serialization API, by implementing the methods, readObject(), writeObject(), writeReplace() or the methods found in

Solution: The default Converter in XStream could be enhanced to support these features.

Outcome: XStream should be able to serialize any object that standard Java serialization can, without any modifications.

2. Improved JVM support.

Current situation: XStream uses reflection to instantiate objects when deserializing. Using plain reflection, this requires each object to have a default constructor, which XStream will call. An ‘enhanced-mode’ is also supported that uses JVM specific calls to construct objects without ever invoking a constructor, guaranteeing no side-effects.

Problem: Currently the ‘enhanced-mode’ is only available if using the Sun 1.4 JVM or later.

Solution: Enhance the enhanced mode to support more popular JVMs, including Sun 1.3, IBM 1.4, and JRockit.

Outcome: More users can use XStream without having to make intrusive modifications to their classes.

3. Configurable mappings.

Current situation: XStream was originally designed as a tool for transparent serialization of objects (specifically for persistence or to send across the wire in messaging systems). As such, the goal was to allow XStream to figure out what the XML should look like on the fly, without forcing the mappings to be defined for each class.

Problem: An unforseen popular usage of XStream is for assembling objects from XML configuration files. However, because XStream has been designed to just figure out the XML on the fly, it does not allow users to (easily) specify their own XML structure.

Solution: To add more simple to use ‘tweaks’ to the generated XML. For example, to allow attributes to be used in some elements, alias elements based on where they appear or remove redundant tags to make the XML easier to understand.

Outcome: More flexibility for the resulting XML, without forcing users to write custom converters.

XStream 1.0.2 released


* Many more converters for common Java types.
* Fields of type byte[] are now encoded using Base64.
* Improved support for using XStream in environments where classes are hot-redeployed.
* More…

Download: Full distribution or Jar only