Code and Snow and Stuff

Musings on software and the quality of the white stuff…

Archive for the ‘development’ Category

Java Thread Sleep Tip


If you often find yourself writing code similar to this:

try {
    Thread.sleep(10 * 1000); // sleep for 10 seconds
} catch(final InterruptedException e) {

You can make your intent a lot clearer (and IMHO cleaner) by doing this instead:

try {
    Thread.sleep(TimeUnit.SECONDS.toMillis(10)); // sleep for 10 seconds
} catch(final InterruptedException e) {

The really nice thing about this approach is that you can substitute the SECONDS to anything else, i.e.,

try {
    Thread.sleep(TimeUnit.HOURS.toMillis(10)); // sleep for 10 hours!
} catch(final InterruptedException e) {



Written by dharrigan

February 8, 2012 at 2:06 pm

Posted in development, java

Tagged with , , , ,

Banning URLs from Varnish using Apache Camel and RabbitMQ – Part 2

Welcome Back!

I hope you found Part 1 on this tutorial useful. You should by now have a running instance of Varnish cache along with a running instance of RabbitMQ. You should also have cloned the Varnish-Ban project from Bitbucket and perhaps had a look through the project structure and source code. I hope there is nothing too unusual in there :-).

In today’s posting we will be covering the following topics:

  • The Varnish-Ban Camel Component
  • Configuring Varnish to respond to HTTP BAN requests.

I hope you enjoy the continuing adventure! :-)

The Varnish-Ban Component

Writing a component to hook into Apache Camel is really quite simple. There are various ways of doing it, but I choose a very expicit and straightforward way to achieve the goal of working with Camel. The main requirements were to:

  1. Create a POJO which implements the Component interface.
  2. Create the Service class that will handle the sending of the BAN request to Varnish.
  3. Add a file called varnish-ban into the folder META-INF/services/org/apache/camel/component. This will allow Camel to auto-register the component.
  4. Create a Camel XML file describing the route and the processing requirements that Camel with respond with.

These steps are described below.

Creating the POJO

Writing the POJO was very simple. Below is a screen shot of the the actual class:

A component in Camel is responsible for creating the Endpoints – in effect it is a Factory.  In my configuration, the Component calls the Endpoint which creates a Producer that invokes the VarnishBanServiceImpl class. I like decoupling of code, so it seemed sensible to me to externalise the actual work of the banning mechanism into a service class that does the work. The service class has the responsibility of sending the BAN request to Varnish. The varnishServerUrl is given to us by Camel when it processes the XML configuration file (see below). The main thing here is we don’t have to do any extra work to obtain the varnishServerUrl – it’s all externalised into the XML file.

Creating the Service Class

The VarnishBanService does all the real work. Fortunately for us, even this class is quite small and very straightforward in its functionality. It simply creates an instance of a HTTP Client (from Apache HTTP Components) and sends off our customised HTTP request (a BAN request) to Varnish:

Our customised HttpRequest – the HttpBan class is very simple:

All that is happening here is that we are extending a base HTTP Class (provided by  HTTP Client) and overriding the getMethod invocation to return our customised HTTP method – cleverly called BAN :-). The toString is a simple helper when we are printing out debug/logging messages. You can create your own particular HTTP Method (SUSHI anyone?) if you have different needs. We could have called our method “LOLBAN” if we wanted to :-)

The remainder of the VarnishBanService class just handles the response back from Varnish and prints out some debug/logging information. Please have a look over to understand how it works. There shouldn’t be any surprises. I’m not handling any exceptions here, but what you could do is wrap up the exception into an AMQP message and shove it back into another Queue for another system to process (a monitoring application for example).

Enabling Auto-Discovery of our Component by Camel

If one creates a file with the same name as our chosen URI (see below in the Camel XML  route configuration section to discover what this is all about), then Camel will automagically register our newly created component and make it ready for use. Like so:

The file has one line in it:

This is all that is required to enable auto discovery in Camel. Pretty neat.

Creating the Camel XML Route Configuration

There are several ways to configure Routes in Camel – one is to use Java DSL to wire things together – another way is to use an XML configuration. I choose to use the XML configuration way just to keep things separate. Underneath the hood, Camel uses Spring, so using an XML configuration file seemed like a nice fit as well.

The file consists of the following elements:

  1. The Source Route. This is our connection to RabbitMQ using the Camel-Spring-AMQP component (see the file applicationContext-beans.xml) in the source code.
  2. What do do when a message comes in (send it on the varnish route)
  3. Splitting the XML payload from RabbitMQ using XPath to obtain the URLs that we wish to BAN
  4. Invoking our Varnish-Ban component against a running varnish instance (http://localhost:6081)
  5. Handling any exceptions that may occur. In this example nothing is done, but we could choose to invoke another Camel component to drop an error message into another queue (banQueueError?)

Configuring Varnish for HTTP BAN Requests

Varnish by default does not permit BANs to occur via HTTP requests. To help encourage Varnish to do so, we need to write a bit of VCL (Varnish Control Language). I’ve put the recipe (a complete VCL file) below (this example is also contained with the conf/varnish/default.vcl file in the Varnish-Ban project):

backend default {
    .host = "";
    .port = "8080";

acl purge {

sub vcl_fetch {
    set beresp.ttl = 5m;

sub vcl_recv {
    unset req.http.Cookie;
    if (req.request == "BAN") {
        if (client.ip !~ purge) {
            error 401 "Not allowed";
        error 200 "Banned " + req.url;

Let’s walk through each section:


This is the backend service that Varnish is fronting – in most cases this will be a webserver. Here I’m instructing Varnish to cache requests from a server running on my local machine and listening on port 8080 (Varnish by default listens on port 6081, so if I hit http://localhost:6081 what will actually be served up is content coming from http://localhost:8080).

acl purge

In this section I’m defining an ACL (Access Control List) list of authorised machines that will be allowed to execute a PURGE (an invented name – I could have called it BANNERS if I wanted to). The ACL is used in the VCL_RECV section.


A FETCH is the response from the backend – in the sense that Varnish has “fetched” the response and potentially cached it. Here I’m saying to Varnish to cache all backend responses for 5 minutes.


A REC(ei)V(e) is the request coming into Varnish from a client. The important things to note here are:

  • I’m removing Cookies. By default Varnish does not cache any requests that contain Cookies.
  • We will do something special if the type of the request (from the HTTP HEADER) is a “BAN” type . I invented this type – it could be called another name.
  • We will only allow those clients defined in our ACL the authority to BAN URLs from Varnish – otherwise we return back a 401 (Not Authorised) to the client.
  • Finally we return a 200 back to the Client once we have finished processing the BAN request.

The example VCL should be put into your “default.vcl” and Varnish restarted. When this is done we are ready to move to the final part of this tutorial!

That’s all for now!

Hopefully by now you will have a running application. In the third and last article of this tutorial we will be sending BAN messages to Varnish and observing the results. Until then, have fun!


Written by dharrigan

January 5, 2012 at 9:23 am

Posted in development, java, software, varnish

Tagged with , , , ,

Automatically Adding JAXB2 Classes to Spring using Annotations

Hi Again!

An annoying aspect of using the built-in Jaxb2Marshaller that is bundled with Spring is the fact that you have to manually add each class to be bound into the XML. This is sooooo boring and old skool :-) Thankfully, it’s not that hard to get Spring to scan all classes in a package for properly annotated classes and have those added to the JAXBContext automatically. I provide below, for your pleasure, an example bit of code that does the job.

Please note: Until (if?) Spring changes Jaxb2Marshaller, you will have to do some xml fudgery to get this to work:

<bean id="marshaller" class="AnnotationJaxb2Marshaller">
    <property name="classesToBeBound">
    <property name="packagesToScan">

The reason is that in Jaxb2Marshaller afterPropertiesSet is marked as final. However, in that method the JAXBContext is initialised, the code borks out if no classesToBeBound is set – therefore I set a dummy (but valid!) entry. The list that holds the set of classes to use (containing our dummy class) will be overwritten by the packagesToScan. Okay enough rabbling, here is the code:

import java.util.Arrays;
import java.util.ArrayList;
import java.util.List;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.annotation.XmlEnum;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlSeeAlso;
import javax.xml.bind.annotation.XmlType;

import org.springframework.core.type.classreading.CachingMetadataReaderFactory;
import org.springframework.core.type.classreading.MetadataReader;
import org.springframework.core.type.classreading.MetadataReaderFactory;
import org.springframework.core.type.filter.AnnotationTypeFilter;
import org.springframework.core.type.filter.TypeFilter;
import org.springframework.oxm.UncategorizedMappingException;
import org.springframework.oxm.jaxb.Jaxb2Marshaller;
import org.springframework.util.Assert;
import org.springframework.util.ClassUtils;

 * An extension to the Jaxb2Marshaller that scans the classpath for classes annotated
 * with the @XmlRootElement (and others) annotation. I don't like typing in the class in
 * classesToBeBound since I often forget which ones I've done!
public class AnnotationJaxb2Marshaller extends Jaxb2Marshaller {

    private static final String RESOURCE_PATTERN = "/**/*.class";

    private String[] packagesToScan;
    private final ResourcePatternResolver resourcePatternResolver = new PathMatchingResourcePatternResolver();
    private final TypeFilter[] jaxb2TypeFilters = new TypeFilter[]{
            new AnnotationTypeFilter(XmlRootElement.class, false),
            new AnnotationTypeFilter(XmlType.class, false),
            new AnnotationTypeFilter(XmlSeeAlso.class, false),
            new AnnotationTypeFilter(XmlEnum.class, false),

     * Scan packages looking for any classes annotated with the @XmlRootElement annotation.
    protected List<Class<?>> scanPackages() {
        final List<Class<?>> annotatedClasses = new ArrayList<Class<?>>();
        try {
            if (packagesToScan != null) {
                for (final String pkg : packagesToScan) {
                    final String pattern = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX + ClassUtils.convertClassNameToResourcePath(pkg) + RESOURCE_PATTERN;
                    final Resource[] resources = resourcePatternResolver.getResources(pattern);
                    final MetadataReaderFactory metadataReaderFactory = new CachingMetadataReaderFactory(resourcePatternResolver);
                    for (final Resource resource : resources) {
                        final MetadataReader metadataReader = metadataReaderFactory.getMetadataReader(resource);
                        final String className = metadataReader.getClassMetadata().getClassName();
                        if (matchesFilter(metadataReader, metadataReaderFactory)) {
                            final Class<?> jaxb2AnnotatedClass = resourcePatternResolver.getClassLoader().loadClass(className);
        } catch (final IOException ex) {
            throw new UncategorizedMappingException("Failed to scan classpath for unlisted classes", ex);
        } catch (final ClassNotFoundException ex) {
            throw new UncategorizedMappingException("Failed to load annoted classes from classpath", ex);
        return annotatedClasses;

     * Determine if any of the classes matches our list of acceptable annotations.
     * @param metadataReader for the resource.
     * @param metadataReaderFactory for the resource.
     * @return true if the class contains the annotation.
     * @throws IOException if anything goes wrong.
    protected boolean matchesFilter(final MetadataReader metadataReader, final MetadataReaderFactory metadataReaderFactory) throws IOException {
        if (jaxb2TypeFilters != null) {
            for (final TypeFilter typeFilter : jaxb2TypeFilters) {
                if (typeFilter.match(metadataReader, metadataReaderFactory)) {
                    return true;
        return false;

     * Why oh why is the afterPropertiesSet in the super class final???
    public synchronized JAXBContext getJaxbContext() {
        if (packagesToScan.length > 0) {
            // We will try *my* way :-)
            final List<Class<?>> annotatedClasses = scanPackages();
            if (annotatedClasses.size() > 0) {
                setClassesToBeBound(annotatedClasses.toArray(new Class<?>[0]));
        return super.getJaxbContext();

     * Set packages to scan.
    public void setPackagesToScan(final String[] packagesToScan) {
        Assert.notEmpty(packagesToScan, "'packagesToScan' must not be empty");
        this.packagesToScan = Arrays.copyOf(packagesToScan, packagesToScan.length);




Written by dharrigan

January 3, 2012 at 11:10 pm

Posted in development, java

Tagged with ,

Banning URLs from Varnish using Apache Camel and RabbitMQ – Part 1


Hello and Welcome! :-)

Over the course of three postings, I would like to present a tutorial on using RabbitMQ and Apache Camel to BAN (their parlance for removing) URLs (objects) held within Varnish Cache. This proposed approach allows for a complete decoupling of application logic from the caching system thus promoting greater flexibility, scalability and resiliance – in effect creating a sophisticated event driven architecture that would grow with business needs. Think about the enormous benefits and potential here – an application-initiated (and as-close-to-possible) realtime event driven mechanism for removing objects from within Varnish!

I hope you find this tutorial useful to you and I welcome any feedback you have. Please do drop me a email or comment if you have anything you wish to add :-)

Before I go any further I would like to sincerely thank the members of my team for doing the initial work on this – Vinay, Diego, Craig, Fred and Manju – your contributions are gratefully appreciated – thanks guys! :-)

In today’s posting I will introduce the key players and describe the  technologies that will be used.

Basic Requirements and Assumptions

These articles are written for Java developers and application support personnel in mind. The language used is Java 7 and the target platform is Unix based (I personally use Debian testing). There are comprehensive instructions on each application website for Varnish and RabbitMQ on how to download, install and do an initial configuration – please have a read and please install each component. The project source code and associated files are hosted on BitBucket as a Mercurial repository.

NOTE: Although the target audience is anyone with a familiarity of Java, the information presented here can be adapted to *ANY* architecture. All you need is a way to send message to a queue, for something to pick the message off the queue and process it, then for something to send on the processed message to a running instance of Varnish. An easy recipe to follow :-)

Architecture Overview

Shown below is what we will be aiming towards for our BAN solution:

The Key Players

Without further ado, let me introduce the core components (the versions in brackets are those that I had when I did this proof of concept):

Varnish (3.0.2)

Varnish Cache is a free sophisticated modern web accelerator that is growing in adoption and use throughout the world. It sits in front of any server that talks HTTP  and caches the response from the backend server. In our experience, Varnish has proven itself to be very reliable, very fast and very easy to configure. If you have a need to dramatically speed up responses to the client, I would highly recommend having a serious look at Varnish to see if it will help you (chances are it will! :-)).

RabbitMQ (2.7.1)

RabbitMQ is an implementation of an enterprise messaging system that talks AMQP (it can support other protocols such as STOMP). RabbitMQ is highly reliable and scalable and a good choice if you are looking for a way to send messages between systems – it will be the “backbone” that facilitates our event driven architecture.

Apache Camel (2.8.3)

A very popular integration framework that knows how to route, split, aggregate and do lots more with messages that flow through it. We will be using Apache Camel to pick messages from RabbitMQ and process them for sending on to Varnish.

Camel-Spring-AMQP [and Spring AMQP] (1.0)

A recently developed component for Apache Camel that speaks Spring-AMQP natively (it uses Spring AMQP underneath the covers). We will be using this component to connect to RabbitMQ.

Configuring Varnish

The default out-of-the-box configuration for Varnish will suffice for now. We will reconfigure Varnish in another posting to support BANing of URLs via a customised HTTP requests. An example Varnish configuration file is included in the project source code (in the conf/varnish directory).

Configuring RabbitMQ

It is important that RabbitMQ is installed with the web management console included – although not a requirement to use RabbitMQ, it really really makes life a lot simplier (and we will be using the web management console to send messages). The simplest thing is to install directly from the download on the website. We will require a Queue to be configured that will hold our HTTP BAN messages. I’m a big fan of images to explain what to do, so please find instructions below:

Log into RabbitMQ Web Management console:

Click on the Queues tab and create the following Queue:

You should see this when you click Add queue:

We now have to associate the Queue to an Exchange (along with a Routing Key):

You should see this when you click Bind:

After achieving this step, you now will have a Queue (banQueue) bound to an Exchange ( with the Routing Key (banQueue). We can now use this queue when we send ban messages.

Configuring Apache Camel

No configuration at the moment is required since the project contains the an example Camel configuration for you to use (in the conf/spring directory). You will probably need to adapt this for your own use later.

Configuring the Varnish-Ban Project

If you have not done so already, please clone the project to your machine. It is a very simple project. Please do have a look around the structure and the source files to learn how I’ve put things together. I’m a big fan of Apache Ivy as the dependency manager and I like to keep things easy using Ant. Instructions are included in the README.MD on how to configure Ivy to work so that you can download the required project dependencies.

That’s all for now!

Hopefully you will now have installed the following:

  • Varnish Cache
  • RabbitMQ with a queue called banQueue ready to receive messages
  • Cloned the Varnish-Ban project and resolved dependencies

In the next posting we will walk through the source code and configure Varnish to BAN URLs based on a customised HTTP Request. Until then, have fun!


Written by dharrigan

December 28, 2011 at 3:43 pm

Posted in development, java, software, varnish

Tagged with , , , ,

RabbitMQ and Camel AMQP

One of the new projects I’m working on has a requirement for Apache Camel to talk with RabbitMQ – a most excellent messaging system written in Erlang. Camel comes with an AMQP component that is based upon Apache Qpid and its implementation of a AMQP messaging client – excellent I thought! Problem is that it doesn’t work with RabbitMQ (at least with RabbitMQ version 2.7.0 that I tested it on). After some googling and asking a few questions at the rabbitmq-discuss mailing list, I managed to get the Camel AMQP component to talk to RabbitMQ – life is sweet! Here is the magic recipe that you need:

java -Dqpid.amqp.version=0-91 -Dqpid.dest_syntax=BURL ......

Notes: I have my build dependency manager (the most wonderful Apache Ivy) pull down the latest Apache Qpid client (0.12 at the time of writing) thus overriding the version linked with Camel (2.8.3 at the time of writing). I always like to bring down the most up-to-date dependencies if possible :-)

Written by dharrigan

December 14, 2011 at 8:42 pm

Posted in development, java

Building JDK8 with Lambda Support

Following my recent trip to Devoxx 2011 and from attending Mark Reinhold‘s and Brian Goetz‘s talks on JDK8 and Lambda, my interest was piqued to try and get this all working for myself. I thought that as I’m doing it and as I might not be the only one who wishes to try this out, I should blog my experience in getting to the point of writing a lambda expression (a closure) and getting it to compile and run using JDK8.


Here are some references to start to learn about JDK8 and Lambda:

  • An excellent PDF slide presentation from Brian Goetz from Devoxx 2011 can be found here.
  • The Lambda specification (JSR335) can be found here.
  • The JDK8 specification (JSR337) can be found here.
  • And of course, the OpenJDK project website can be found here.

Any further references will be linked in this article text.

Stop! Read Me First!

As pointed out on the mailing-list, there are already bundles available to you if you only want to try out JDK8 with Lambdas. This posting is only for people who wish to keep at the bleeding edge and compile from source, quicker than the bundles are released for general consumption. Using prebaked bundles is a far easier route and a quicker entry into learning what this exciting new feature brings to Java :-) I would encouage you to try out the bundles and save yourself time in doing all the stuff described below. Saying that, if you do want to build from source, then please do read on…

Some prerequisites:

This is my starting point. Some basic requirements have to be met before you can build JDK8 with Lambdas:

  • I am running Debian Testing within a VM using Parallels to build the JDK:
    • configured with 2 virtual CPUs and 2GB of RAM
  • JDK7 is required to build JDK8:
    • apt-get install openjdk-7-jdk
    • apt-get build-dep openjdk-7-jdk
  • You need mercurial installed:
    • apt-get install mercurial

Please note: You don’t need Debian to compile JDK8 with Lambda, this is just my way of doing it. You can compile in Solaris, MacOS X, RedHat, Centos and even Windows…please refer to the build instructions on supported build platforms and architectures.

Obtaining the JDK8 with Lambda source code:

Currently, to build JDK8 with Lambda, one needs to clone a separate repository away from the main JDK8 repository. This special Lambda repo contains the code changes to the JVM and other bits to make lambda expressions work. It actually pulls down all the other base JDK8 source files but has special source files for switching on Lambda. Once cloned, the build instructions are the same as if one was compiling the base JDK8 packages. Therefore, the first thing you need to do is clone this Lambda-aware repo:

hg clone

When cloning has finished, pop into the lambda directory and run:

sh ./

This will clone the other dependent repos (such as hotspot, corba, jdk, langtools and so on) into the lambda directory. This process shouldn’t take too long – a few seconds or so.

From this point onwards, the build instructions on the OpenJDK for building JDK8 apply. The instructions do talk about JDK7, but the same rules apply for JDK8 (I guess they just have to be updated). There are a few gotcha’s which I have done my best to document below:

Obtaining JAXWS and JAXP source code:

This is quite easy. Just look in the jaxp/ file for the name of the JAXP version to download, I then used wget to retrieve the zip archives, i.e.,

  • wget
  • wget

You want to put those zip files into a directory outside of the lambda cloned directory. I have mine in a directory called “drops.” Do the same for JAXWS. Just look in the jaxws/ file for the name of the JAXWS version to download. Put the zip archive files into the “drops” directory along with the JAXP files. For those interested, here is what my drops directory looks like:

If you are curious about my overall directory structure, I’ve attached a screenshot below. Please note that I build openjdk8 in addition to the lambda project, that is why I have a do_openjdk script file and an openjdk8 folder (and why in my drops folder I have jdk8 versions of JAF and JAXWS):

Cloning (and building) the defender-prototype project:

For the moment, it is necessary whilst building JDK8 with Lambda, to include another very important project in the build process. This project uses reweaving to enable defender methods that are a cornerstone of using Lambdas with Java. Eventually the JVM will be clever enough to understand defender methods, but for now we need a special javaagent called jsr335-agent when building JDK8 with Lambda. This agent is built from the defender-prototype project.

The first step is to clone the defender-prototype repo into the same level as the lambda project (see below for a screenshot):

hg clone

The second step is to download the required library dependencies. You need to create a folder called “lib” in the defender-prototype directory and drop in the following two jars:

  • testng-6.2.jar
  • asm-4.0_RC1.jar

You can find these jars from the testng website and the asm website.

Finally, you can build the jsr335-agent.jar

  • ant

The output of this will be a file called jsr335-agent.jar in the distrib directory.

Here is a screenshot of my directory layout now. Please note the defender-prototype directory at the same level as the lambda directory:

Pretty isn’t it? :-)

Building JDK8 and baking in Lambda support (FTW!):

This part is the easy part. Nothing much to do here. I wrote a little build script (called to automate the build process. You can clearly see where I put this script from the screenshot above:

export LANG=C
# JDK7 is required to build JDK8 with Lambda support
export ALT_BOOTDIR=/usr/lib/jvm/java-1.7.0-openjdk-amd64
# The location of JAXP and JAXWS source zip files
export ALT_DROPS_DIR=/home/david/development/openjdk8/drops
cd lambda
sh ./make/scripts/ pull -u
. jdk/make/
make sanity && make all

Whilst the build is happening, you can go make a coffee or a nice cup of tea. It will take a while.

Writing your first Closure (or Lambda!):

Now comes the time of great rejoicing and excitement. Now, for the first time, you can write closures in Java and functions are treated as first-class citizens! If I am honest here, I’m not that familiar with functional/closure type programming but I’m quite eager to learn. I took a few minutes to knock up an example, so below I give you a little Hello World!

public class HelloWorldClosure {

    interface C {
        String c();

    public static void main(final String[] args) {

        final C c = () -> "Hello World";


And of course, the result:

Not bad for an afternoon of hacking around. :-)

I’m very excited in this new language feature coming in JDK8. It is a much-needed addition to Java now that we live in the age of multi-multi-core computers :-) I wish to thank all those on the Expert Group for their continued development of Lambda’s for Java – even for an average-joe type programmer like myself, I’m sure I will use them extensively :-)

Written by dharrigan

November 20, 2011 at 6:54 pm

Posted in development, java

Devoxx 2011, JDK8 and other things…

It’s been a while.

Yesterday afternoon, I returned from attending Devoxx 2011 in Antwerp, Belgium. I not sure I’ll be going back again for some time…

  • It was super crowded. Stefan (the Organiser) allowed an extra 200 or so attendees even after the initial cap of 3,200 attendees. It was hard to get into some presentations. I think it is time to either restrict the number of people or find another venue.
  • Obtaining lunch was really really badly organised. Just two long tables (4 rows) to cater for +3,000 people during lunch! I gave up, went outside and grabbed some food outdoors.
  • It was *very* Android-oriented. Whilst I accept Android is an important platform, this is a Java developer conference and I wanted more Java based presentations.
  • Some of the presentations were very badly put together. I believe as a minimum, as a English-based conference, the presenter should be able to express themselves clearly in English.
  • It was announced that next year in April there will be a Devoxx in Paris, France with over 75% of the presentations in French – not a problem since they are catering for a need.
  • I pity the presenters who have the house lights glaring at them continuously, more than one complained they couldn’t see the audience when taking questions.
  • Not enough hands-on coding sessions – let’s have more hacking and slashing sessions on interesting topics – like, let’s all get JDK8 downloaded, compiled and do something JDK8-y.
  • By doing this coding session (for example), this would encourage people to perhaps contribute to the OpenJDK project if more people can download, compile and run it.

Generally I was underwhelmed this year. Given that these presentations eventually wind their way to Parleys, I may just pay for a subscription and watch the videos from the comfort of my own home.

One of the things that *did* manage to get me excited this year was seeing JDK8 and closures starting to take more shape. I was really impressed by Brian Goetz’s presentation and it got me eager to get home and try out JDK8. I’ll post another article when I’ve been playing around with it a bit more.

Things that I did find interesting:

  • JSR107 – The long-lived specification for Caching. At long last it is ready (nearly – some final hurdles have to be jumped through)
  • jHome – A very fun presentation by a fun Brazilian guy. It made me want to wire up my coffee maker immediately :-)
  • Continuous Delivery – I’ve implemented this in my workplace (insofar as I can do at the moment). I truely believe in being able to do this.
  • A good presentation by Mark Reinhold about Java 7, 8 and 9. I’m quite interested to see what may come in Java 9…
  • Freud – a tool I never knew existed but I can see the benefits of such a tool immediately. I can check things across my system to ensure nothing bad leaks across abstraction layers.
  • Play 2.0 looks pretty awesome. I should be able to prototype and even launch a few ideas I have with this tool without the heavyweight nature of Enterprise development.

Saying all that, I’m glad to be back now in London. An interesting aspect of my time spent abroad (without a decent internet connection in the hotel) was I started to play around with iOS development and managed to write 2 little apps as Proof Of Concepts to help me learn Objective C. That impressed me – how easy it was to do :-)


Written by dharrigan

November 20, 2011 at 12:09 pm

Posted in development


One of the really nice things about Mercurial is that it comes with a lovely script called It allows me to view side-by-side my commit message along with a list of commits in Vim (my editor of choice). Since, in my new workplace, we are using Git, I decided that I couldn’t live without this wonderful feature.

After an hour or so of playing around – mostly trying to figure out why git wouldn’t show me a diff, I managed to get something up and running. You can find it here:

There are two bugs that I’m aware of so far. First one when I create a new commit that only contains new changes and no diffs and secondly when it is the initial commit. To get round these, simply execute git commit -am “commit message”

Hope you enjoy it!


Written by dharrigan

May 17, 2011 at 3:57 pm

Posted in git, mercurial

Devoxx 2010



Hi All!

I’ve been attending the most excellent Devoxx 2010 conference here in Antwerp, Belgium. It has been a truly fantastic experience and very encouraging to see the amount of enthusiasm from all across Europe for Java. It was mentioned at the conference that Java is not just a language, or a development toolkit, or a committee, but it is more than that. Java is also about community. I believe that most of Europe had attendees at the conference – I heard a lot of accents from a lot of people (3000+ during the week!).

Some of the highlights for me personally include:

  • Meeting the Java Posse Guys and participating in a live broadcast (#330).
  • Seeing some personal heros including Josh Bloch, Mark Reinhold, Brian Goetz, Bill Venners, Joe Darcy and Linda Linda DeMichiel. These guys are amazing!
  • Learning more about (and hacking away at) Scala – a very interesting language.
  • Meeting Juergen Hoeller – the Spring Principle Engineer.
  • Attending Martin Odersky’s presentation on immutable objects – fascinating!
  • Learning about Project Lombok – wow wow and triple wow. Why didn’t I know about this project sooner????

Seriously, I could go on more, but there was just too much happening to take it all in! My recommendation? Devoxx 2011 awaits…

Some other things:

  • I’ve created a Twitter account – and I’m finding it useful! Crazy but true! My handle is @davidharrigan.
  • Found an amazing Portugese resturarant called Cabo Verde – man, so much tasty food.
  • Got some ideas for some apps I want to create

All in all, it has been a richly rewarding experience and I hope to be back again next year for Devoxx 2011! :-)


Written by dharrigan

November 19, 2010 at 8:11 pm

Posted in development, java

Tagged with , , , , ,

Adding Test Dependencies To The Example Project

Apache IvyThis post follows on from my previous post where we set up Ivy and cloned an example project. I hope you had time to look at the code and at least manage to compile the example. Excellent!. As promised, we are going to add in a very simple unit test for the HelloWorld#saySomethingToUpperCase method. However, in order to do that we need to bring in JUnit and another favourite library of mine Hamcrest.

Telling Ivy about where to find the good stuff

To help Ivy find dependencies, it needs to know where to search. It does this by using a resolver. A resolver is nothing more than a way, be it http, ftp, file system (and others) that knows how to look for artifacts. Let’s look at one now:

<ibiblio name="repo2" m2compatible="true" root="" />

This resolver is actually “baked into” ivy. It doesn’t have to be explicitly declared, but I believe it makes it clearer later on what is resolving to where if we are up-front about everything to begin with.

What the heck is ibiblio and what does this resolver do? Ibiblio is a public digitial archive that just so happens to also store lots and lots of artifacts as a public service. It stores these artifacts in a way that is maven 2 compatible. Ivy knows how to work with Ibiblio to find stuff. What you may notice however is that instead of giving Ivy the Ibiblio address, we are using the maven repository – this is okay – I’m using the functionality that the Ibiblio resolver gives me, but instead pointing Ivy to look at another repository (which just so happens to be maven 2 compatible as well…). Ivy gives you that flexibility of reusing a resolver that knows how to do “stuff” but get the resolver to look elsewhere for files.

We will be using the Ibiblio resolver quite a bit…

Let’s add that line into our ivysettings.xml file…

<chain name="default" returnFirst="true" checkmodified="true" changingPattern="*-SNAPSHOT*">

        <ibiblio name="repo2" m2compatible="true" root="" />



So far so good. We have edited ivysettings.xml to add in a resolver. This resolver will tell Ivy where to look for dependencies. We can now leave ivysettings.xml alone for a while…

Adding in JUnit

It is now the turn of the ivy.xml file. When Ivy is asked to fetch dependencies (or resolve in Ivy-speak), Ivy looks to the ivy.xml file and the ivysettings.xml file. We have told ivy.xml where to look for dependencies, now we have to tell Ivy what dependencies are required. Let’s do that now:

In the ivy.xml we are going to add just one line that will tell Ivy to go fetch the JUnit library – smart!:

<dependency org="junit" name="junit" rev="4.8.1" conf="test->default" />

What does this all mean? Well, it means:

  • There is an dependency that lives in a repository somewhere called junit.junit
  • The particular version of the junit.junit we want is 4.8.1
  • Our test configuration will depend on junit.junit’s default configuration

The last point, configurations, will be talked about in a later article. We will leave that for now. Another question is where on earth do you find out the names of the dependency – it’s organisation, it’s name, what revisions there are??? The answer is to use mvnrepository to search for what you want. If you go there now and type in junit, you will see that the top hit is the dependency we are looking for. If you click on the link and drill down past the revision 4.8.1, you will see that mvnrepository helpfully shows what we need to type into our ivy.xml to pull down this dependency (minus the conf details).

Let’s add that line now to ivy.xml


    <dependency org="junit" name="junit" rev="4.8.1" conf="test->default" />


What happens if the library we are after is not in mvnrepository (such as some Sun/Oracle Jars)? An interesting question and one which we will talk about later in a following article. Also, in the interests of fairness, you can lookup artifact information from the Sonatype Nexus Maven Repository in addition to mvnrepository.


Already we have covered quite a bit. We have not only told Ivy where to look for dependencies (the maven2 repository) but now we have declared that our module depends upon the JUnit artifact. We can use mvnrepository to look for libraries that we require and we can simply add the helpful information that mvnrepository gives to us into our ivy.xml file. After a short while, once you become familiar with using Ivy and using repositories you won’t even have to look at mvnrepository for the commonly used jars since you will be able to easily guess what to put into your ivy.xml file.

Adding in Hamcrest

Before we write a little bit of code, let’s add in one more dependency:


    <dependency org="junit" name="junit" rev="4.8.1" conf="test->default" />
    <dependency org="org.hamcrest" name="hamcrest-all" rev="1.1" conf="test->default"/>


I hope you see how easy it is to add in a dependency.

Writing a simple unit test

For the sake of brevity, this is what my unit test ( looks like (you can find this in ivy-example2 source code – detail of how to download are at the bottom of this article):

package com.dharrigan;

import static;
import static org.hamcrest.core.IsEqual.equalTo;
import static org.junit.Assert.assertThat;

import org.junit.Test;

public class HelloWorldTest {

    final HelloWorld helloWorld = new HelloWorld();

    public void saySomethingShouldRespondWithHelloWorldUppercased() {
        assertThat(helloWorld.saySomethingToUpperCase("ivy!"), is(equalTo("IVY!")));

Running our Unit Test

Cool, time to run our unit test…If you execute:

ant test

in the project folder, you will see some real magic. Not only will Ivy go and get the dependencies for us, but it will put them in the right place. The project should compile and the unit test should run and pass with flying colours (or green colours at least)…

Building and Testing using Ivy

Building and Testing using Ivy

What just happened?

As part of the build step, Ant asked Ivy to resolve all dependencies. Ivy looked at the ivysettings.xml file to find out where to resolve dependencies from, then it looked at the ivy.xml file to find out what dependencies had been declared. It then went out to the internet, downloaded the dependencies and stored it in your machine. After it had done that, it placed a copy of the jars into the libs/test directory. Ivy was now done. Control was passed back to Ant which compiled the classes (using the jars that Ivy just downloaded) and ran tests. I would encourage you to have a look around the project structure now and see what has been added (hint: libs) and how the compilation proceeded.

What is cool about this?

Well, if you where to run:

ant test

again, Ivy would know that it has already downloaded these jars so it won’t go out to the internet again. This will save enormous time when building projects.


Ivy copied the jars into the right location in your project without you doing anything. Ivy uses patterns for placing the jars in the right location. The pattern it uses is completely configurable by you. I have it configured to put it into the libs/[conf] directory (i.e., libs/runtime, libs/test, libs/build-support and so on…).

These are big wins in my book and already we have covered the day-to-day use of Ivy!


We have discovered how we can add a resolver to the ivysettings.xml file and we have discovered how to add dependencies into your ivy.xml file. Then, we have watched as Ivy did a resolve when building the project and how the unit test worked. Finally we have talked about some of the bonuses of doing it the Ivy way :-)

Getting hold of the source

To view the source directly, you can clone it from here:

hg clone


git clone git://

Coming up next

In my next article, I’ll be covering some of the behind-the-scenes work. I will be talking about my ant build files, how Ivy places files in the right location using patterns and the local ivy cache. I hope you can join me in that adventure!


Written by dharrigan

October 10, 2010 at 11:42 am

Posted in ivy

Tagged with , , ,


Get every new post delivered to your Inbox.

Join 54 other followers