mere technology …its all just ones and zeros


Subversion installation on Eclipse Ganymede

Getting Eclipse to talk to Subversion is still hard work, as of Eclipse Ganymede. Heres the quick no nonsense route to getting up and running;

There are two alternate plugins that you can use to do this:

Go into the update managed and add the following update sites:

Dont worry about picking cherrypicking all all the subpackages, just install everything from each site.


Add this guy as a site for plugins:

And you should check that you also have this guy available:

Again, just save time and install the lot from each of these

Note that the above sites tend to change from time to time, you might need to check them in your web browser first.


Web Resources for understanding JCA

Its always been a challenge to find good accurate information on the Java Connector Architecture, and in particular on how to build connectors. Here is a loose collection of resources useful for digesting the Java JCA.

Tagged as: , 1 Comment

Forthcoming books in the RESTful WebServices space

There seem to be a number of promising books upcoming in the RESTful WebServices space....

Any others out there?

Tagged as: No Comments

RESTful Web Services in Java

Ive been soaking up pretty much everything I can find on REST recently. Some time ago I was about to start a new human web project, and thought designing it RESTfully might possibly be a good idea. Since then, I have read Sam Ruby/Leonard Richardson's excellent tome RESTful Web Services, and have become convinced that it is.

Being a long time Spring advocate, I have watched closely the gradual emergence of Spring 3.0, which is looking to fill in a lot of its gaps in REST support. Most interestingly, its server side implementation has come as the next great adventure with Spring MVC, and not its already mature Web Services effort framework.

Spring of course is certainly not alone, or anywhere near first in this area with several significant projects arguably at a much greater level of maturity.

JAX-RS (JSR-311)

The main non-Spring thrust for RESTful WS in Java, has become centered around the recently finalised JSR-311, known as JAX-RS. This is not to say that the RESTful Java story begins with a Sun standard (perish the thought). At least one of the RESTful java efforts (RESTlet) predated JSR-311 quite significantly, but is now an adoptee of the JSR. There are at least the following open source implementations that I know of:

Of these, the only one I have spent any real time kicking the tyres on is Jersey. Although this is billed as the reference implementation from Sun, it seems to have some ambitions to penetrate the real world a lot further than other reference rollouts that Sun have provided in the past. So far, my entire experience of JAX-RS is limited to Jersey, so I wont trouble you with my as yet non-expert opinion of these, expecially as Solomon Duskis has been working on a comparrison of these implementations.

I will note though just a few things did strike me very quickly when running through a few representative scenarios with Jersey:

  1. The annotated API looks intuitive. With classes representing (Restful) Resources, and some easily recognisable annotations such as @GET, and @POST, etc. The initial learning curve looks pretty manageable.
  2. Getting started with Jersey is trivial. This is really just a credit to the good work done by the Sun guys, to provide lots of easy entry points to their project, including some useful maven2 archetypes that get you up and running with an executable (albeit Grizzly WebServer hosted) Hello World service, quicker than you can say "HATEOAS".
  3. Resource Instances per Request?. Instances of the Resource classes appear to be instantiated on every request. That I am suprised by this, could just be the newb in me showing. More likely it is coming from a Spring MVC Controller standpoint whereby the handler of the request is a managed global singleton. This wasnt immediately obvious from running a Hello World example as these only support GET, but as soon as I wanted to implement a mutative method like POST(a) I realised I was in trouble.

    I would think that the Resource-Object-Created-On-Request pattern would not lend itself so well to dependecy injection frameworks like Spring which prefer to create upfront, and directly manage beans. Im sure there are plenty of ways around this, but it didnt seem to be the most natural approach. Perhaps this is the reason why the Spring guys did not themselves go down the JAX-RS route?

Other non-JAX-RS efforts

With the relative freshness of JSR-311, there are other efforts as well floating around that havent adhered to the spec. Other than Spring 3.0 itself, one worth noting is Josh Devins Mattress Framework. Josh also notes the Resource-Object-Created-On-Request pattern as a reason for not adhering to the spec. With very little community involvement however, rather than Mattress becoming a major player, its largest contribution may be to provide a running, mostly functional technical comparrison to JAX-RS.

Certainly for those who have been burnt in the past by Sun's 'spec first' approach, lightweight functional alternatives are always great to see.

Client Support

One area with possibly the greatest divergence is that of support for the client. Spring is offering its RestTemplate in the style of other boilerplate-hiding templates that they have proved successful with. Others in the JAX-RS camp have been reusing aspects of the spec on the client side, even though this is beyond scope of the spec itself.

What Im looking for

I am very interested to see how Solomon's comparrison progresses, not only to know which (if any) technology is worth investing my time (ahem career) in utilising, but also to see what method he takes in comparrison. Hopefully the same approach can be expanded to consider the effectiveness of non-JAX-RS efforts.

Im also interested to know if there is a reference application out there (preferably not involving any more pets or pet stores!) that might be useful in such a comparrison of frameworks.

Finally I am interested to see how successful any of these approaches are in providing for server side convergence of runtime code supporting both the human web and the machine web. How can architect the server side for a future that embraces both humans and machines as clients of the same resources? Building out on their MVC framework puts Spring well down this path, but is their new REST support strong enough?

Update. A couple of other JAX-RS implementations that are floating around:

  • Apache Wink - looks to largely be a new collaboration between teams at HP and IBM
  • Triaxrs - which appears to be gunning for the OSGi space

Good to see some more activity.


Spring 3.0 further down the pipeline

Interesting news from SpringSource this morning, with Spring 3.0 Milestone 3 released. Milestone 2 had been available for some time, but uptake (even early adoption) was I suspect limited largely due to the lack of updates to the documentation.

This new release includes some embryonic documentation, which at least covers the basics on some of the new features.

Some things of note for 3.0:

  • Changes to the Spring project structure supporting modularisation (read OSGi)
  • Both client and server side offerings for REST support. Interestingly this is all in the MVC area, and does not appear to have involved the existing Web Services project at all.
  • Quite a bit of new configuration options that have been pulled in from the JavaConfig project

Quite a bit has been said about the place already about the REST support. One of my favourites was Rick Evans at the London Spring User Group way back in December. Also see Arjen's blog for more recent material.

What is more of a suprise was the inclusion of the JavaConfig features directly into the main Spring project. JavaConfig has looked promising for some time, (particularly where it comes to providing a component model without taking the full OSGi plunge), but hasnt looked like making a 1.0 release any time soon. Perhaps this step marks the beginning of the end for JavaConfig as a separate concern?

I think the decision to grow REST support out of the MVC framework suggests a couple of really interesting things:

Firstly the technological convergence of the web MVC support and the REST WS support, basically into the same thing, will mean that developers working on projects targeting either the human web or the machine web, will not need to add very much in order to support both. Its really just a case of Content Negotiation. I think this makes a lot of sense, and will only add more momentum towards the RESTful WS camp. Spring of course are not the first to do this, but they bring with them influence over the majority of java developers, many of whom will be reconsidering the design decisions underpinning their existing java webapps.

Secondly, with Spring now offering support for both RPC style web services and, RESTful web applications and services, it will be interesting to see which side of the fence receives the bulk of the attention from the Spring developers themselves going forward. Whilst they espouse offering choice to the community, the decisions they make on their internal development efforts are always pretty telling.


Clojure goes 1.0

News just in, Rich Hickey has announced the release of Clojure v 1.0.

Great news for the Clojure community and congratulations to Rich. Clojure has been quite useable for some time now, so it will be interesting to see if the notional shift to a 1.0 release will help it to attract any more of the increasing dynamic language mindshare circulating around the JVM. Some may not like its Lispness, but beyond that hurdle, Clojure looks to me to be a leading contender at this point in the race.

Tagged as: No Comments

On Clojure

I attended an interesting meetup the other night of the London Java Community group. Rich Hickey, the author of Clojure spoke about his motivations for creating the language, and what it was all about.

Clojure is a new language written for the jvm aimed particularly at addressing concurrency issues that plague java and other Object Oriented languages. Written as a Lisp, Clojure is a functional language that treats data structures as programs, and enforces the usage of immutable objects. Rich and others, see the proliferation of mutable objects as the bane of many large systems built using todays mainstream OO languages and expect the concurrency problems related to these to massively increase as we enter the multi core processing era.

By runnning on the JVM - an already stable platform with market saturation, Clojure, as with Groovy and others leverage much of the hard won programatic support enjoyed by java developers, such as garbage collection. It is interesting to see new language development move in this direction, as it greatly reduces the implementational scope for new languages to address.

Will be interesting to watch how Clojure progresses, and see if it really will make all our concurrency dreams come true!


InfoQ has a roundup today on what it new and interesting in the world of Clojure. One of the interesting facets of the language is that because the vast majority of the language is written in Clojure itself . The remainder (ie that which is platform specific) is actually a really small set of core operations.

This  means that it is relatively easily ported to other platforms such as CLR and (believe it or not) Javascript! The possibilities of the exact same language running on both the client and server in a web situation are interesting to say the least.

Tagged as: No Comments

Would the real software architect please stand up

Mike Walker recently blogged about the breakdown of the 'architect' metaphor commonly used to align the notion of a high level software designer with that of the Construction industry.

Mike listed several areas where the model of a building/construction architect really does not fit with that of a software architect.  In many cases this is a function of industrial maturity. As pointed out,  Construction has many thousands of years greater experience in understanding and defining the role and responsibilities of the architect, whereas Software is so young that it has had to borrow the title in the first place.

Simon Brown followed up questioning why project sponsors seldom hold software architects accountable for project success as in the Construction industry. The flipside being that software architects then lack the authority to fully realise their vision.

For me the most important breakdown in the metaphor comes with identification. This too is the greatest impediment to software architects assuming additional authority that may or may not be useful.

When the holder of a role cannot easily be identified, then all the responsibilities,  accountabilities and expectations cannot easily be attributed to them. Consider, why do police wear uniforms?

In Construction it is very easy to distinguish the architect from developers. The architect dresses differently, works at different times and locations, associates with different people event to the extent of being almost in a different social class. Their engagement with a project must necessarily begin far in advance of any development stage and their output reach advanced stages of completion prior to the commencement of development.

By contrast, the software engineer sits at a desk, with a computer, almost always side by side with the developers of the product. More and more often the architecture is not fully embodied ahead of time, and may develop to a much greater extent in parallel with general development.

Differences in the career path also add to the ambiguity.  In Construction, the career path to architect is generally academic and does not incorporate very much of the same training given to a developer. Building architects are seldom developers in a past life, and do not develop as part of their role.  In Software the roles are much more inextricably linked. Architects who do not code risk becoming astronauts, whereas the best of whom tend to be those most willing to delve deeply into code.

Like all metaphors the architect is useful to a point but tends to get over extended. We need to recognise that whilst the distribution of responsibilities falls differently across software teams as it does to those in construction, at the end of the day the same level of responsibility and accountability needs to be born by the team. Construction may have 10000 years head start, but without this, Software as an industry cannot hope to graduate to the same level of rigour.

Filed under: Architecture No Comments

Great article on Spring Security 2.0

Came across a really excellent article on the ACL (Access Control List) side of Spring Security. This covers Spring Security 2.0.x which is the project formerly known as Acegei. There isnt a lot of documentation around for the ACL side of Spring Security 2.0 and the whole area  in not easy to navigate without some sort of guide.

The chaps at Denksoft Blog really went the extra mile on this one.

Update: Found another useful discussion. There really isnt much out there documenting the nuances of this, so I reckon anything like this is gold for the intrepid developer


W3C friendly links with JSTL Core URL tag

The JSTL Core tag library offers a really useful url tag for generating URLs for html links from within JSP. This is particularly useful when there are one or request parameters that need to be carried along with the URI.  They can be specified like this:

<a href="<c:url value="/next.htm">
<c:param name="personId" value="${}"/>
<c:param name="preferredTitle" value="Mr"/>

In this example there are two request parameters. The first (personId) is resolved from an in scope variable, and the second (preferredTitle) is supplied directly to the tag. This would produce something like the following:

<a href="/next.htm?personId=5&preferredTitle=Mr" />

The problem
Whilst this may work in your browser, by default, (at least with JSTL 1.1) the URL produced does not validate with respect to the W3C standards. This is because the produced link contains an unescaped ampersand to separate the request parameters:


The problem of course is not so much the ampersand itself, as the fact that it has been left unescaped when the link was rendered.

One possible solution
... is to use the JSTL Core out tag when producing the href link like this:

<c:url var="nextLink" value="/next.htm">
<c:param name="personId" value="${}"/>
<c:param name="preferredTitle" value="Mr"/>

<a href="<c:out value="${nextLink}" escapeXml="true" />">

Adding the var attribute assigns the generated URL to the in scope variable nextLink. This allows the subsequent c:out to access the generated URL. Because c:out supports the escape of XML characters, the ampersand separating the request parameters is resolved to its escaped format &amp;

- which makes Mr W3C very happy indeed!

Tagged as: , , 2 Comments