Here, we explain how Deployit‘s Infrastructure and new Release Overview features help you achieve this goal.

Continuous Delivery & the Release Perspective

In today’s highly competitive economic environment, the need to bring new features to market quickly, flexibly and reliably is paramount – a goal that is ultimately the aim of the main IT trends Cloud, Agile and DevOps.

Continuous Delivery – extending Continuous Integration to automatically transition applications down the Dev-Test-Acc-Prod delivery pipeline – is a key component of this strategy. In order to be able to effectively implement this, your ARA solution needs to allow your developers – or, in larger organisations, release or DevOps teams, to quickly and efficiently answer questions such as:

• How far is MyApplication down the road to Production?
• When will MyApplication take the next step down the road?
• What do I still need to do before that next step can be taken²?

Ideally, this dashboard would also allow you to plan MyApplication‘s next step and calculate the estimated go-live data, perhaps even based on an analysis of previews versions of MyApplication.

(Virtual) Environment Management & the Operations Perspective

From an Operations point of view, an individual application is only a small part of the picture. Across your Dev-Test-Acc-Prod landscape, you will need to track all applications vying for these environments, to manage potentially conflicting resource requests, plan environment maintenance activities and the like.

Since these environments are often owned and managed by different teams and certainly have varying service levels, you will also want to limit your view to one or a subset of these environments at a time.

Your Operations or DevOps teams need to know:

• Which application versions are currently deployed to my environment(s), or were deployed at a certain point in time?
• Which components do these applications consist of? On which middleware and infrastructure systems are these components deployed?
• What are the current values of any properties or settings for these components? Which environment-specific customizations have been applied?

Cloud and the on-demand environments it enables will eventually replace the rigid Dev-Test-Acc-Prod distinction³. Nevertheless, the ability to present an environment-centric view will still be required, since virtual environments will still be owned by different groups or teams. Indeed, such a perspective will be even more important if you want to effectively combat “virtual sprawl”.

While the coming generations of “true” cloud architectures will hopefully reduce the shared resource conflicts that greatly complicate much of today’s Dev-Test-Acc-Prod management, databases, legacy systems and external payment providers are not likely to disappear anytime soon.

In fact, Facebook, Twitter and other social elements of your future business services may even increase the number of shared resources you need to manage!

Incorporating ARA Data in the Service Delivery Picture

Whilst your ARA solution should be your “go-to” platform for answers about how your applications and environments relate, it is equally important to consider when this data might be more effectively embedded in a broader service delivery picture.

For example, your ARA platform is not a good candidate for providing a release calendar, since it is not aware of much of the information that is relevant in this context, such as CAB⁴ meeting schedules, business sign-off dates or operational maintenance windows.

It is thus important to ensure that your ARA solution can make its data accessible via APIs such as RSS feeds, iCal calendars and other APIs, to enable effective integrations with the rest of your service delivery tooling.

Conclusion

The right Application Release Automation platform gives your Delivery and Operations teams fast, accurate insight into your application environments and delivery pipeline.

Choosing a solution like Deployit with focused Operations and Delivery overviews as well as open APIs for easy integration into your overall Service Delivery dashboards and reports greatly enhances the accessibility and effectiveness of your application release management.

What early adopters have learnt is that, at the enterprise scale, automating release execution quickly introduces a new bottleneck in today’s dynamic IT environments: continuous management of the deployment plan definition. A new generation of application release automation (ARA) tooling avoids this pitfall by leveraging intelligence to automate deployment planning as well as execution.

The State of ARA

Given how strongly our IT industry is dedicated to the automation of processes, it is nothing short of amazing how much of the deployment of our own solutions depends on manual actions coordinated more or less effectively between large groups of people.
Indeed, a recent analyst report noted that the majority of large enterprises were still relying on manual application release processes or on in-house scripting understood by only a small number of specialists, operated as a black box that – hopefully – will do its job and will most likely necessitate a painful troubleshooting session if it doesn’t.

With key IT trends such as Agile, Cloud and DevOps dramatically ramping up the frequency of application releases in order to increase responsiveness to business needs and provide more and better services to customers, it’s clear that this situation cannot continue.

Thinking of today’s common release processes, it is also hardly surprising that the initial drive has been to automate the actual rollout of the application itself: copying the files to the target machines, restarting the servers, running the SQL against the DB etc. Using a defined workflow to organise these activities makes lots of sense: fewer failures, no more missing steps or steps executed in the wrong order, no more typos, better visualization etc.

Lessons from the First Generation

Ironically, using one of these first generation ARA tools at an enterprise scale quickly made it obvious to early adopters how much effort is required to maintain the substantial number of workflow definitions that quickly accumulate to support full deployments, partial upgrades, rollbacks, environment scale-outs etc. across an enterprise application portfolio.

Of course, this is not a new challenge: ask anyone who has had to update 100 build job definitions in a continuous integration tool to change a compilation parameter, or 100 test plans in an automated testing setup to accommodate a different target browser, just how time-consuming and error-prone this type of maintenance is.

It’s not as though these modifications are unique per process. They tend to be systematic changes that reflect changes to the overall deployment strategy and/or context. The issue is that these first-generation tools, where all the deployment intelligence is stored in the power user’s brain, simply do not have enough internal knowledge of the structure of deployment to assist effectively.

The Next Level of Application Release Automation

A new generation of Application Release Automation includes this intelligence. These advanced tools² no longer require hand-holding by your power users every step of the way, and encode knowledge of deployment best practices and strategies to automate the planning and execution of deployments.³

No pre-provided strategy can be a 100% fit in an enterprise environment, so the strategies must be configurable, of course. Once your power users have fine-tuned them, however, all the individual deployment plans – initial installations, full and partial upgrades, downgrades, undeployments, scale-outs etc…easily hundreds across an application portfolio – are automatically tailored to your scenario.

This becomes even more efficient the fewer deployment strategies are in play, so these tools also motivate and reward increased standardisation of deployment procedures, in itself a valuable business goal. In fact, with a suitable interface and integrations into the development pipeline you essentially have an enterprise Platform as a Service, potentially on a private or hybrid cloud.

Conclusions

With adoption of Application Release Automation rapidly on the increase, a new generation of solutions are appearing that automate deployment planning as well as execution.
Based on the challenges experienced in scaling the first generation of ARA tools to enterprise levels, these next generation solutions are designed to eliminate “continuous expert hand-holding”, promote standardisation and allow organisations to create a “software factory” that continuously delivers business value.

In this post (an extended version of which is available as a whitepaper), we will outline today’s Release Management challenges and discuss the need for Release Automation.

We’ll identify key considerations for successful solutions and highlight why “Zero-Maintenance” is a critical requirement for Release Automation that provides the scalability required in an agile landscape and enables the delivery of continuous business value.

(more…)

A key part of the test harness for the original versions of Tweetstore that run on the Google App Engine is the neat GoogleDevServer class. Basically, it’s a clever wrapper around the KickStart class used under the covers by the GAE SDK tools that allows you to specify the SDK location, address, port and WAR file (or expanded WAR directory) to run.
Better still, it can programmatically be shut down cleanly, making it ideal for integration test runs¹.

For CloudBees, I was thus looking to put together a similar RunAtCloudServer. It proved more challenging than expected…²

Just spawn a container already?

Both the maven-gae-plugin and the bees-maven-plugin allow you to spawn a local GAE or RUN@cloud server simulation, of course. These can easily be integrated into your Maven build, for instance as part of your pre-integration-test setup. So why not just stick with that?

Well, for some scenarios that can be perfectly sufficient. For Tweetstore, having an inline server that cleanly shuts down allows us to:

• run integration tests alongside unit tests from an IDE without having to remember to start an external process
• debug the application running in the server on demand, without having to mess with remote debuggers or figure out a way to sometimes get the Maven plugins to start in debug mode
• work some conditional magic with the server arguments

If your project’s requirements are similar, an inline server might be a good option. And luckily, the code’s already been written!

Hangin’ around

The RUN@cloud SDK’s version of KickStart is the StaxSdkAppServer³. Figuring out the correct arguments for the launchServer factory method wasn’t too hard, so I hooked up a StaxSdkAppServer and kicked off the test.

Started like a charm! Then the test finished and…just hung on in there. Over in the trusty debugger⁴, I could see not one, but two zombie threads still running. The design was based on a “shutdown-by-JVM-kill” scenario, I guess.

Assassins and other Ninja Tricks

The first of the two threads is a Timer that something called the WebAppEngine uses to do…well, who knows? In any case, we can get a reference to it with a decent handful of reflection and cancel it. Easy enough.

Our remaining zombie is a bit more elusive, unfortunately. It’s a thread spawned by an instance of the RequestMonitorValve class in a manner analogous to

new Thread(idleTimer, "requestMonitor").start();

So no reference, and no way of interrupting it. However, the idleTimer Runnable is referenced and repeatedly calls a handler as part of its execution. How about injecting a handler that throws an exception to end the thread?

Nice idea, but it turns out the thread really doesn’t want to die that way:

while(true) {
    try {
        // do stuff
        if(callbackClient != null)
            callbackClient.updateStatus(state);
    } catch(Exception e) {
        // increment some error counters
    }

    try {
        Thread.sleep(statusIntervalSecs * 1000);
    } catch(InterruptedException interruptedexception) { }
}

So I’ve had to go one better and throw a ThreadDeath error instead. Urgh.

Now you see it, now you don’t?

The remaining gotcha involves injecting the catchily-named KillerCallback into the idleTimer. Even using reflection, this is a elementary concurrency failure because without a synchronized-with relationship⁵ between injecting the new handler and invocation of the handler by idleTimer, there is no guarantee the new handler will actually be visible to the thread we’re trying to stop.

Such a relationship could be established if the “assassin” was injected before the thread that runs idleTimer starts. Unless we want to override library classes, that would mean setting it after creating but before starting the StaxSdkAppServer⁶…which unfortunately doesn’t work either because the instances referencing idleTimer are only created when the server starts.

So?

So, for now the potential concurrency issue is documented and we hope for the best No problems observered so far…

Seeing Double

TrueZIP uses a de.schlichtherle.truezip.fs.spi.FsDriverService provider configuration file in META-INF/services to register drivers for various archive formats, and the checker was failing because one of the required drivers wasn’t being loaded, even though the code was correctly included in the jar-with-deps.

The duplicate option of Ant’s Jar task³ and Gradle issue 1050, which talks about merging files during archive creation, hint at what the problem is: once packaged up in a single jar-with-deps archive, only one of TrueZIP’s provider configuration files was being found.

Maven, Gradle and Java

Once I examined the jar-with-deps constructed by Maven⁴, it was pretty clear why: the JAR only contains one of the configuration files – looks like the first one encountered in my case, but that may be non-deterministic. Presumably, this happens because Maven uses a temporary directory to prepare the archive contents, which of course can’t hold multiple files of the same name.

With Gradle⁵, things are a bit more interesting because the archive does indeed contain all the configuration files – the ZIP format supports duplicate entries⁶. However, ClassLoader.getResources doesn’t play along, so again only one entry is found.

There Can Be Only One

Basically, it seems that merging the affected files is the only feasible way around this. Here’s a possible Gradle snippet⁷:

task jarWithDeps(type: Jar, dependsOn: classes) {
	mergeDir = "${buildDir}/merge"
	// might need a lazy var in a multi-module project where deps are inherited
	runtimeDeps = configurations.runtime.collect { zipTree(it) }

	doFirst {
		new File(mergeDir).delete()
		mergeFiles(mergeDir, runtimeDeps, file-to-merge)
		// ... possibly other files too
	}

	// this project's classes and all deps
	from sourceSets*.classesDir
	from(runtimeDeps) {
		exclude file-to-merge
	}
	from mergeDir
}

private def mergeFiles(targetDir, fileTrees, relativePath) {
  // prepare the merge
  mergedFile = new File("${targetDir}/${relativePath}")
  new File(mergedFile.parent).mkdirs()

  fileTrees*.matching({ include "**/${relativePath}" })*.each {
    mergedFile << it.bytes
  }
}

Unfortunately, I haven’t been able to find a similar option for the Maven Archiver, but I guess there must be something out there in the Maven ecosystem

Edited 21/07/2011 to add: The sample code now includes possible solutions suggested in comments. Run gradle clean jarWithDeps2, mvn clean package -Pwith-shade-plugin or mvn clean package -Pwith-keystone-plugin⁸ to try them out.
Edited 25/07/2011 to add: You can now also run mvn clean package -Pwith-services-handler to see how the Assembly plugin’s <containerDescriptorHandlers> can take care of this too.

In the previous post, we looked at how Reusable commands, Models and Conventions++ helped turn build from a “black box” process into the “just works” experience we know today.

We then shifted back to deployment and identified Develop a common model, (Re)discover vanilla and Support a “clean build” as three key steps required to achieve a similar transition.

Develop a common model

Before we can advance to the ‘model’ stage, we first…well…need a model. Thankfully, a very simple one can suffice: Packages, Environments and Deployments.

There’s nothing particularly magical to this, and indeed the concepts are commonly found in most organisations. But giving these things explicit labels helps not just formalize the ideas and gives developers and vendors something to support. It also creates a shared vocabulary and language around deployment, which is the first step to shared understanding and reusable functionality.

Indeed, the concepts are so basic that there does not appear to be much to say about them.

Packages capture the components of the versioned item to be released, both artifacts represented by actual files as well as configuration, resource settings and metadata.

In accordance with release management best practice, packages should be stored in a DSL and should be independent of the target environment, so that you have one “gold standard” package running in Development, Test, QA and Production.

Packages also mean that we can version everything, not just the application binaries but also the related configuration and environment settings.

Development and Test just mentioned are examples of Environments, simply collections of infrastructure – physical, virtual, long-running, on-demand, whatever – that applications run in as they progress through the ALM cycle, potentially with approvals or other checkpoints governing the transition from one to the next.

Deployment, then, is perhaps the one concept not immediately widely understood. A Deployment represents not just the activity of getting a Package running in a certain Environment, with a start and stop time, executing user, status and so forth.

Rather, a Deployment also documents the way in which the Package’s components have been deployed and, if applicable, customized. For instance, a Deployment will record that a certain EAR file in the package has been deployed to the following target server(s) or cluster(s), or that the data source password for this specific environment has been customized and set to a new value.

Recording this information is critical because it is very hard to be able to intelligently and correctly modify an application’s state – when upgrading to a new version, for instance, or adding new servers to the target cluster – if you do not know where and with which settings the application is currently running.

(Re)discover vanilla

If we are going to achieve hassle-free, push-button deployments, another thing we will have to reconsider is whether we really need to tweak and customize our infrastructure in every way possible. Indeed, some companies seem to almost have a policy that any setting that might be a default should be regarded with suspicion and, preferably, changed.

Much as custom project layouts made setting up a build unnecessarily tedious and complicated in a convention- and model-based system, stubbornly refusing to go with infrastructure defaults will make it harder to get hassle-free deployments that truly cover all the steps required.

Sticking with defaults not only encourages reusability because the chances are much higher that a solution developed for a different scenario will also work in yours. It also improves maintainability and cuts down on the risk of “ripple” changes, where a custom value in the setting for the servers hosting application X requires further changes to the setup of application Y etc.

Support a “clean build”

When building a large project, we try to cut down on the time taken by recompiling only the source code that has been modifying. When deploying applications, we similarly want to save time when upgrading to a new version, especially when this time represents production downtime.
However, we also know that, eventually, some parts of any incremental build will end up going out of sync, causing strange compilation problems, or features or fixes not appearing when they should.

What do we do in such a case? Do we laboriously try to track down the files that are out of sync and rebuild piece by piece? No, we simply run a clean build to start from scratch, because in 99% of cases it’s much quicker to simply rebuild than try to track down the cause of the problem.

In deployment-land, we seldom have the ability to clean build, and this is one of the main causes for the stressful, time- and resource-consuming troubleshooting hunts that are still far too common. Of course, in order to clean build a system we need full versioning of the environment, its configuration and the applications deployed to it. Virtual appliances and virtualization solutions with snapshot capabilities will have a major role to play here.

We also need a known state for durable resources such as databases, which remains challenging but is being addressed by a growing number of products out there.

Push button deployments

Taking stock, it’s clear that there is still some way to go. We’re slowly developing a common model, but both “(Re)discovering vanilla” and “Supporting a “clean build” are visions not quite yet on the horizon of most large companies.
In fact, it’s not so much technological advances that are required – many startups are pretty close to push-button deployments and continuous delivery. Indeed, the “poster children” of this movement already have setups where every commit can pass through an entire regression, integration and performance testing suite and potentially go straight to production.

No, the important hurdles to be taken are procedural and mental, changing rusty ways of working and entrenched mindsets. For those that can make it, though, the benefits in terms of accelerated business value are already proving to be game changers.

In the previous post, we compared deployment to another key process in the application lifecycle – build – and asked which key developments turned it from a magical “black box” into the “just works” process it is today.

We identified Reusable commands, Models and Conventions++ as three key steps, which we’ll look into in more detail in this post. Then, we’ll shift back to deployment and ask which improvements will be essential to getting to “just works” here.

Reusable commands

The first step, epitomised by Apache Ant, was the recognition that most of the low-level tasks or actions are the same whatever application is being built, whether calling a compiler, copying files or replacing placeholders.
Rather than copy-pasting the same OS commands into every new build script, we encapsulated these commands as libraries of reusable components that only needed to be written once.
Further, we discovered that certain patterns of step sequences would appear in many different builds. These ‘chunks’, such as constructing a classpath, or copying and processing static resources, evidently represented some higher-level build activity with a distinct function.

Models

Whilst the realisation that all the actions carried out in a build are basically a sequence of common chunks was an important start, the next big advance was brought about by recognising that we weren’t just seeing repeated patterns of actions, but that the types of data these actions were working on were also shared.
This gave rise to the notion of a true domain model for application builds, with source sets, resource sets, modules, dependencies and so forth that were originally introduced by Maven and have featured and been reused in all build systems since.

Combining the sequence of common chunks with the new domain model that structured the data being processed gave rise to notion of distinct phases, in which parts of the build model are generated, prepared and made available to subsequent commands.
In addition, Maven also supported the idea that the domain model, and thus the build phases, would have to be able to vary slightly to accommodate different types of Java artifacts that need to be delivered, such as JARs and EARs. This has subsequently been further developed to support builds of totally different technologies such as Adobe Flex applications.

Conventions++

An additional benefit of domain models for build was the ability to make use of default values in a structured way, for instance for the names of built artifacts or the location of resource files.
However, the flip side of this convenience, certainly in combination with XML as a descriptor language for builds, meant that deviating from these standards could be quite a challenge. Certainly if the aim was to extend the domain model in some way, or to support a language or technology whose build flow was reasonably different from Java’s, such as building documentation bundles or virtual machine images, for instance.
This has led to a generation of build tools, such as Gradle, that aim to restore the developer to a position of full control in which arbitrary actions can easily be defined and organised into phases, tasks and entire builds. Of course, given how used we have become to the convenience of “it just works” in simple cases, these tools still support the full domain models and conventions of common technologies such as Java.

Who’d have thought?

Reviewing this progression from today’s perspective, a couple of facts stand out that, certainly in comparison to other evolutions in IT, are quite surprising.
Firstly, whilst it’s now hard to imagine specifying a dependency using anything other than the groupId:artifactId:version pattern, none of the models or conventions that developed were formalised in industry standards. Instead, they were either based on observations of common patterns, or simply clever or even somewhat arbitrary choices (src/main/java, for instance).
Secondly, we have seen how ease-of-use based on conventions, coupled with a moderate nuisance factor of tweaking those conventions, can dramatically change user behaviour. Initially, for instance, many of those new to Maven spent quite a significant amount of time, and produced a fair amount of XML, to change the standard settings to match their own environment, naming conventions, file paths etc.
Pretty soon, though, and especially as the ratio of green field vs. legacy projects increased, it simply became easier to stick with Maven’s standard values and be done with it. Today, these conventions have become so standardised that they are supported not just by Maven, but essentially all other build systems out there, too.
It’s not just users’ preferences that were “charmed” into adopting standard conventions, though. In many cases, company standards previously seen as cast-iron were progressively discarded or modified if they could easily not be accommodated by the emerging de facto standards. Ease-of-use was able to triumph against abstract rules.

And deployment?

So much for the build process. What about deployment, today’s critical hurdle for automation in the business value delivery chain? As previously mentioned, the current industry average is somewhere between “black box” and “step sequence”. In terms of the descriptions of the build process evolution, the most advanced deployment automation systems are somewhere just beyond “reusable commands”, in other words.
Which naturally begs the question: how do we get to a push-button state? What do we need to do to be able to reach the maturity level of build today?
Looking at what we encounter in the industry today, three critical aspects will be:

1. Develop a common model
2. (Re)discover vanilla
3. Support a “clean build”

We’ll cover the details of these three concepts in the next blog…

In this first post, we’ll focus on some of the changes and trends across the industry that have brought such increased business attention to the area of release, deployment and management of applications.

As companies focus on tuning their IT environment on rapid delivery of business value, more and more projects and initiatives within organisations are looking at the entire value chain of software production.

Whether under the banner of Devops, via integrated project teams or as part of the introduction of new development methodologies like Agile¹ or infrastructure technologies such as cloud², there is a growing awareness of the need for automated, reliable and flexible deployment procedures.

Whilst it’s clear that the generation of customer features takes place within the development, testing and QA teams, the business value inherent in these features is only unlocked once the application is actually running in a target environment, accessible to users. And it’s not just the final release to production that requires a deployment: every UAT, performance or integration test generally needs an application running in a “real” environment, not a developer’s local machine. One test, one deployment.

Given the well-known costs and adverse effects of faulty software in production, the ability to raise quality, usability and performance through a greatly increased number of testing cycles represents significant added value in itself.

One of the consequences of this increased attention is that the importance of build, release and deployment professionals as deliverers of business value is being recognized more and more. The heightened focus also means, though, that many companies are realizing that the effectivity, simplicity and overhead of their release and deployment processes lag far behind that of build and continuous integration.

As my role at XebiaLabs involves studying, automating and improving deployment processes across the industry and helping developing our vision for deployment into the future, the question of why deployment is so different from build in today’s enterprises was bound to raise its head sooner or later. The resulting discussions and reflections formed the basis for this series.

What’s in a word?

One of the challenges surrounding the discussion of deployment in relation to build, release, provisioning and other tasks in the ALM space is the – decreasing, thankfully – lack of a clear shared definition for deployment. Without wanting to promulgate this as the correct definition, for the context of this discussion I’d like to treat deployment as the process that

takes the components that make up a release (typically a specific version of an application) and getting them correctly set up in an infrastructure environment so that the release is accessible to (end) users

This would differentiate it from build and release in that it assumes that the application components have already been created, and from provisioning and other infrastructure tasks in that the target infrastructure is already assumed to be present.

On-demand virtual or cloud environments, or virtual appliances, put a bit of a different spin on the issue, and will be a topic for a subsequent blog.

Blast from the past

Taking the above as our working definition, the sobering picture is that, with very few exceptions, deployment now is pretty much at the stage where build was in the days of the make guru: a black box put together and operated by a specialist that somehow works. With luck, this precious resource is still employed and around to fix or extend things when required, but if he or she is out to lunch you’re simply out of luck.

To be fair, there are quite a few places where there is least tooling or automation in place that tries to map out the sequence of steps or actions required to carry out a deployment, to at least bring some visibility and traceability and shine some light on the ‘magic’. But this is still a long way away from the push-button experience that build is nowadays. Laboriously visualizing and walking through a process step-by-step is still a sign ultimately of a lack of trust; a truly mature process doesn’t display its internals any more, it “just works”. Much like build today.

The road to “just works”

Of course, build didn’t start out as a “just works” process either, so what actually were the steps that made this transition possible? Looking at the evolution of Java build tooling over the past decade or so, there have been at least three main developments:

1. Reusable commands
2. Models
3. Conventions++

We’ll dive into the details of these three concepts in the next blog…

if (threadContextLoader != null) {
  loadFromContextLoader(className);
} else if (systemLoader != null) {
  loadFromSystemLoader(className);
} else {
  loadFromBootstrapLoader(className);
}

and realized that it’s not immediately evident how to do this in a uniform way. But actually, it’s quite simple…getting a ClassLoader object for the bootstrap loader is just a couple of lines of code.

So what’s the problem?

Well, if you’re happy with a literal implementation of the pseudo-code above, there obviously isn’t a problem.

ClassLoader loader = Thread.currentThread().getContextClassLoader();
if (loader != null) {
  return loader.loadClass(className);
}

loader = ClassLoader.getSystemClassLoader();
if (loader != null) {
  return loader.loadClass(className);
}

// null is the bootstrap loader
return Class.forName(className, true, null);

But this is very procedural code¹, and it would already be much more OO if we could do something like:

getLoader().loadClass(className);

ClassLoader getLoader() {
  ClassLoader loader = Thread.currentThread().getContextClassLoader();
  if (loader != null) {
    return loader;
  }

  loader = ClassLoader.getSystemClassLoader();
  if (loader != null) {
    return loader;
  }

  return ...???????
}

The problem is that there simply isn’t a ClassLoader.getBootstrapClassLoader() or equivalent method. You can try to walk up the system loader’s parent hierarchy, of course, but what you’re likely to find is that the bootstrap loader will be represented by null – not very useful in our circumstances.

Writing BootstrapClassLoader

So what we want is to come up with a ClassLoader implementation that delegates straight to the bootstrap loader. One option would be to override loadClass to simply call Class.forName with the above arguments, but there’s actually an even easier² way:

class BootstrapClassLoader extends ClassLoader {
    BootstrapClassLoader() {
        /*
         * The default classloader implementation will use the bootstrap loader
         * if it finds a null parent.
         */
        super(null);
    }
}

Now we can finish our getLoader method:

// or simply "new ClassLoader(null) {};"
final ClassLoader BOOTSTRAP_LOADER = new BootstrapClassLoader();

ClassLoader getLoader() {
  ClassLoader loader = Thread.currentThread().getContextClassLoader();
  if (loader != null) {
    return loader;
  }

  loader = ClassLoader.getSystemClassLoader();
  if (loader != null) {
    return loader;
  }

  return BOOTSTRAP_LOADER;
}

Unless we’re being really performance-conscious, we can even turn this into the almost functional³:

ClassLoader getLoader() {
  return Iterables.find(asList(Thread.currentThread().getContextClassLoader(),
      ClassLoader.getSystemClassLoader(), BOOTSTRAP_LOADER), Predicates.notNull());
}

There’s a demo snippet on PasteBin here.

At XebiaLabs, however, we’re not just the implementors of our plugin SPI. We also write the deployment engine that consumes these plugins. And unfortunately, there isn’t much out there to help you read, load and verify services. Hence MultiSPI.

What about ServiceLoader?

Evidently, the engineers at SunOracle – as prominent SPI consumers – shared this frustration. In Java 6, they introduced ServiceLoader to at least make “vanilla” SPI consumption easier. MultiSPI isn’t just a fully-compatible alternative for those still working with Java 5, however. It also supports a number of common additional use cases:

1. Inspecting the list of class names before they are loaded, for instance to remove or replace some items (think user-definable overrides), to use different class loaders for different packages (think OSGi) etc.
2. Inspecting the classes before they are instantiated, for instance to check for required annotations or implemented interfaces, to delay creation of instances etc.
3. Using non-vanilla instantiation strategies, for instance to support factory methods, or in conjunction with dependency injection etc.

Providing services in 2011

More importantly, though, MultiSPI doesn’t just support reading service implementations from META-INF/services files. Because let’s face it, if you’re designing a component-provider mechanism today, it probably won’t be based on the vanilla SPI specification.

MultiSPI supports annotation- and manifest-scanning out-of-the-box, but you can add providers for any scheme of your choice, be it XML descriptors, system properties, environment variables or whatever. Of course, you can also mix and match different providers, especially useful if (as in our case with Labs) you are supporting multiple versions of an SPI.

SPIs and dependency injection

Ultimately, of course, SPIs are just service factories, and if you’re working within a dependency injection context you probably don’t want to invoke an SPI loader explicitly, you just want the resulting services to “be available” for injection into your business logic.
Indeed, Spring added a ServiceLoader-backed factory in 2.5, and of course you can do the same with MultiSPI, whether you want the implementation class names, the classes or the instances themselves. There’s Spring and Guice examples; here’s the Spring context that prepares a set of class names, classes and instances, for example:

<bean id="multiSpi" class="com.qrmedia.commons.multispi.MultiSpi">
  <constructor-arg>
    <set>
      <bean class="com.qrmedia.commons.multispi.provider.MetaInfServicesProvider" />
      <bean class="com.qrmedia.commons.multispi.provider.AnnotationScanningProvider">
        <constructor-arg value="uk.gov.mi6.LicenseToKill" />
        <constructor-arg value="uk.gov" />
      </bean>
    </set>
  </constructor-arg>
</bean>

<bean id="agentNames" factory-bean="multiSpi" factory-method="findImplementationNames">
  <constructor-arg value="uk.gov.mi6.Agent" />
</bean>

<bean id="agentClasses" factory-bean="multiSpi" factory-method="findImplementations">
  <constructor-arg value="uk.gov.mi6.Agent" />
</bean>

<bean id="agents" factory-bean="multiSpi" factory-method="loadImplementations">
  <constructor-arg value="uk.gov.mi6.Agent" />
</bean>

Of course you can use many different MultiSpi instances, with different provider configurations, in your application at the same time.

Using MultiSPI

To use MultiSPI, just add the following dependency and repositories to your POM:

<dependency>
  <groupId>com.qrmedia.commons</groupId>
  <artifactId>multi-spi</artifactId>
  <version>1.0-SNAPSHOT</version>
</dependency> 

<repository>
  <id>qrmedia-releases</id>
  <url>http://aphillips.googlecode.com/svn/maven-repository/releases</url>
  <releases>
    <enabled>true</enabled>
  </releases>
  <snapshots>
    <enabled>false</enabled>
  </snapshots>
</repository>
<repository>
  <id>qrmedia-snapshots</id>
  <url>http://aphillips.googlecode.com/svn/maven-repository/snapshots</url>
  <releases>
    <enabled>false</enabled>
  </releases>
  <snapshots>
    <enabled>true</enabled>
  </snapshots>
</repository>

If you think you might run into conflicting dependencies and want something that just works without having to deal with <excludes>, you can use:

<dependency>
  <groupId>com.qrmedia.commons</groupId>
  <artifactId>multi-spi</artifactId>
  <version>1.0-SNAPSHOT</version>
  <classifier>jar-with-dependencies</classifier>
</dependency>

instead.

The Maven site and project reports are here.