Running a Spring Batch Job in The SpringSource Application Platform

Engineering | Dave Syer | May 30, 2008 | ...

In this article I will show you how to run a Spring Batch job in the SpringSource Application Platform. I ran an early version of this up as a little demo for JavaOne, and then again at the London Spring User Group, and thought it might be a good thing to share. The sample code is here.

The Bundles

First we'll do a quick tour of the bundles in the sample code. Start the server now, or at any point after you have installed some bundles.

Bundle: hsql-server

This one is useful to have around for development and testing. All it does is launch an instance of HSQLDB in server mode, so that you can connect to it and inspect the database using SQL statements. You can just drag and drop it into the Platform Server instance in the Servers View. Do this first, because the Platform remembers the order in which bundles were installed, and starts them in that order. This one has to be started first because other bundles will try to connect to the database server.

The bundle configuration is in META-INF/spring/module-context.xml (this is conventional for Platform bundles) - Spring DM picks up all XML files from META-INF/spring. This one just uses Spring to configure and launch an instance of the HSQL Server.

There is an integration test that can be used to check the…

Open Source, Open Strategy: The SpringSource Manifesto

Engineering | Rod Johnson | May 27, 2008 | ...

As an open source software provider, we think we should be open about our strategy, too. We'd like to share how we got here, where we're going and why the journey will be good for Spring, good for Spring users and good for SpringSource.

Our History

The Spring story began in 2001, when I began working on the 30,000 lines of framework code I published along with Expert One-on-One J2EE Design and Development in 2002. My objective was to help others to avoid the pitfalls that I had encountered completing J2EE projects since 1999.

It quickly became clear that others liked the ideas in that code - such as Dependency Injection and the Spring data access abstraction - and benefited from putting them into practice. I was approached by readers who requested that I publish the code and who wanted to contribute.

I quickly came to see some important benefits of open source.

  • Most users get the functionality they need for free
  •     	<li> It…

Implementing Enterprise Integration Patterns part 0

Engineering | Iwein Fuld | May 19, 2008 | ...

After my talk on Spring Integration I've been getting quite some questions on clarification and samples. To meet the demand I will start a small series on implementing different integration patterns using Spring Integration. This first article will focus on the basics. It will show you how to get up and running and walk through one of the samples.

If you never heard about Spring Integration before it might be a good idea to familiarize yourself with it reading the introductory blog Mark Fisher wrote about it or by browsing the project website. In general

Let me start with a disclaimer: the…

Why should I care about OSGi anyway?

Engineering | Adrian Colyer | May 15, 2008 | ...

InfoQ has a discussion thread summarizing the reactions to the announcement of the SpringSource Application Plaform. Michael Burke asked a great question on that thread which can be paraphrased as "forgetting the hype surrounding OSGi, what benefits can I expect to see if I port an application currently packaged as an EAR to OSGi bundles?".

I started answering this question on the InfoQ thread, but my answer was growing too long for a comment so instead I'll address it here.

The question is a good one. The main difference you will see in an OSGi-based application versus a traditional JEE EAR-based application is improved modularity. So the question becomes, does this improved modularity bring me any benefits, and if so what are they? The book "Design Rules, The Power of Modularity" gives a very thorough treatment of the question. It's great background but I get that feeling that Michael may be looking for something a little less theoretical than what you'll find in that book…

Spring Web Flow 2 Released; Introduces New Faces and JavaScript Modules

Releases | Keith Donald | May 15, 2008 | ...

Dear Spring Community,

We are pleased to announce general availability of Spring Web Flow 2. Download | Documentation

Spring Web Flow is the project in the Spring Portfolio that focuses on providing the infrastructure for building and running rich web applications. As a Spring project, Web Flow builds on the Spring Web MVC framework to provide:

  • A domain-specific-language for defining reusable controller modules called flows
  • An advanced controller engine for managing conversational state
  • First-class support for using Ajax to construct rich user interfaces
  • First-class support for using JavaServerFaces with Spring

The modules of the Web Flow 2 distribution and their relationship with the Spring Framework are illustrated below:

What's in Web Flow 2

Web Flow 2 Distribution Components


Spring Web MVC

The Spring Web MVC framework, a module of the Spring Framework distribution, provides the foundation for developing web applications with Spring using the proven ModelViewController paradigm. Each of the modules of the Web Flow distribution builds on this foundation.

Spring Web Flow

The Web Flow module is a MVC extension that allows you to define Controllers using a domain-specific-language. This language is designed to model user interactions that require several requests into the server to complete, or may be invoked from different contexts.

Spring JavaScript

Spring JavaScript is a JavaScript abstraction framework that makes it easy to write unobtrusive JavaScript to progressively enhance a web page with behavior. The framework consists of a public JavaScript API along with an implementation that builds on the Dojo Toolkit. Spring.js aims to simplify the use of Dojo for common enterprise scenarios while retaining its full-power for advanced use cases.

Spring JavaScript can work with any server-side framework. The Web Flow 2 distribution includes convenient integration between Spring JavaScript and Spring Web MVC for processing Ajax requests.

Spring Faces

The Spring Faces module contains Spring's support for JavaServerFaces. This support allows you to use JSF as a View technology within a familiar Spring MVC and Web Flow Controller environment. With this architectural approach, you combine the benefits of the JSF UI component model with the benefits of a Web MVC architecture. Spring Faces also includes a lightweight component library built on Spring JavaScript for declaratively enabling Ajax and client-side validation behaviors in a progressive manner.

Themes of the Web Flow 2 Release

In addition to introducing the new Spring Faces and Spring Javascript modules, the Web Flow 2 release effort addresses two major themes: Integration and Simplicity.


Across each of the modules, the Web Flow 2 distribution adds a number of interesting integrations that allow you to enrich your web applications. These integrations support:

  • Using Spring Security to secure your flows in a declarative manner
  • Using Tiles for JSP page composition and Ajax partial-rendering
  • When using JSF, using Facelets for page composition and layout
  • When using JSF, using Apache Trindad and JBoss RichFaces component libraries
  • Using the Dojo widget system in a progressive and unobtrusive manner; a manner that degrades gracefully if JavaScript is not available on the client


The flow definition language has been simplified tremendously in Web Flow 2 while becoming more powerful overall. These simplifications include:

  • An appoximate 50% overall reduction in lines-of-code when comparing a version 2 flow definition with its version 1 equivalent (example: version 2 vs version 1)
  • A concise syntax for invoking actions using an Expression Language (EL), with support for both the Unified EL and OGNL
  • Declarative model binding and validation, with support for convention-over-configuration
  • Support for reuse at both the flow and state levels using flow definition inheritance
  • Enhanced modularity, allowing a flow and its dependent resources to be packaged together in a self-contained bundle

Release Notes

  • Web Flow 2 requires Java 1.4 or greater and runs on all major Java EE platforms including Tomcat, Jetty, Websphere, WebLogic, and JBoss.
  • Web Flow 2 requires Spring Framework 2.5.4 or greater.
  • Web Flow 2 has been certified by SpringSource as "Platform Ready" and is fit to run on the SpringSource dm Server in OSGi-enabled web applications.

Getting Started

  • To get started using a build system such as Maven or Ant+Ivy, access Web Flow artifacts from the Maven Central Repository.

Additional Community Resources

  • Watch the interview where the release and Spring JavaScript are discussed with Dion Almaer.
  • Explore Spring Web reference applications on-line. The Spring Travel application showcases the integrated Web Flow 2 feature set and is included in the distribution. The SpringSource Enterprise Bundle Repository is a real-world application in production built on Spring 2.5 and Spring Web Flow 2.0.
  • If you are an existing Web Flow 1 user, review the migration guide to help in upgrading to Web Flow 2. The WebFlowUpgrader tool automates the conversion of your flows to the version 2 syntax
  • Track updates to the Web Flow source repository with Fisheye
  • Watch for upcoming articles on Web Flow 2 by subscribing to

Portability, Fish and Chips

Engineering | Rod Johnson | May 09, 2008 | ...

It's been great to hear so much discussion on the SpringSource Application Platform, online and on the floor here at JavaOne. One of the most insightful comments is from WebSphere transaction architect Ian Robinson:

Does any of this affect WebSphere? Well, nothing has changed in the core Spring framework. Regardless of what the future holds for the SpringSource Application Platform, the core Spring framework project remains complimentary to WebSphere. Like fish and chips.
Ian is exactly right. The SpringSource Application Platform is another choice for Spring deployment. Nothing has changed in…

Working with SpringSource Application Platform's provisioning repository

Engineering | Andy Wilkinson | May 09, 2008 | ...

One of the main advantages of the SpringSource Application Platform is its ability to provision dependencies on an as-needed basis. The benefits of this are two-fold: it ensures that the Platform's memory footprint is as small as possible and it allows applications to be deployed without encapsulating all of their dependencies in a monolithic deployment unit, e.g. a WAR file. To take advantage of these capabilities you will require an understanding of the Platform's provisioning repository and this blog intends to provide just that.

Where is the provisioning repository and how does it work?

By default the Platform's provisioning repository can be found in the repository directory at the root of the installation: Directory structure of the provisioning repository As you can see, there are three main directories: bundles, installed and libraries. installed is for the Platform's internal use so we'll focus on the bundles and libraries directories here. Each contains a number of subdirectories to separate the different types of dependencies:
  • ext contains external dependencies that are provided with the Platform but are not part of the Platform itself.
  • subsystems contains all of the subsystems that comprise the Platform.
  • usr is initially empty and is intended to contain user-added dependencies, i.e. anything upon which your applications depend that is not already provided by the Platform.
The Platform searches the repository directory structure for both bundles and libraries during its initial startup. I'll talk about how this searching can be configured later on in this entry. As bundles and libraries are found within the repository, details of their symbolic names, exported packages etc. are added to an in-memory index of the repository. Upon completing the scan the in-memory indexes are cached to disk. Minimising the Platform's startup time was a priority for us during development. This caching allows the Platform to save some time during startup: it can skip the scan unless it detects that the contents of the repository have changed.

Runtime provisioning

In a plain OSGi environment a bundle's dependencies can only be satisfied by other bundles which have already been installed in the environment. For example, installing and starting a bundle that imports the org.apache.commons.dbcp package will fail if no bundle which exports that package has already been installed. This can be a real pain for users as they have to manually install all of a bundle's dependencies. Thankfully, the SpringSource Application Platform improves upon this significantly by dynamically installing dependencies on an as-needed basis.

When a deployed application is started by the Platform its…

SpringSource Application Platform Manifest Headers

Engineering | Glyn Normington | May 08, 2008 | ...

The SpringSource Application Platform is constructed from OSGi bundles and supports applications which are also constructed from OSGi bundles. The Platform supports the standard features of OSGi, but it also supports some additional manifest headers. Several people have asked Why did SpringSource add proprietary headers? and What are the semantics of the new headers?, so this post explains the background motivation and the semantics of Import-Library and Import-Bundle.

Standard OSGi Bundle Support

The Platform is built on the OSGi R4.1 standard, or JSR 291 if you prefer, and uses Equinox as its OSGi implementation. The result is that you can develop standard OSGi bundles using the Platform's tooling and deploy those bundles on the Platform, as a number of users have been doing since the Platform's launch.

So OSGi savvy developers can use the Platform as a standard OSGi container and benefit from Platform features such as:

  • the ability to deploy bundles using the Admin Console or by dropping bundles in the Platform's pickup directory,
  • diagnostics such as resolution failure diagnosis, application specific trace, and automatic deadlock detection,
  • strong integration with Spring and Spring Dynamic Modules, for developers who want to use these frameworks, and
  • automatic provisioning of dependencies from a repository.
However, the Platform also aims to make it easy for enterprise application developers with little or no prior exposure to OSGi to benefit from OSGi, which places some extra requirements on the Platform.

Additional Requirements of Enterprise Applications

As Sam's recent blog on the Platform's deployment options explains, you can deploy existing monolithic WAR files on the Platform with no need to understand OSGi - the Platform takes care of everything for you. But to benefit from shared libraries, shared services and, ultimately, PAR file scoping, it is necessary to break monolithic WAR files into OSGi bundles. How hard can that be?

Well, some steps in the process are relatively easy, especially if good software engineering practices have been followed and the code has been organised into service, domain, and infrastructure components. These components can be converted into bundles and the dependencies between them expressed using standard OSGi Import-Package and Export-Package headers in META-INF/MANIFEST.MF.

A more difficult step is expressing dependencies on enterprise frameworks such as Spring and Hibernate. It is entirely possible to express these dependencies using standard OSGi Import-Package and Require-Bundle headers, and this is exactly what you should do if your aim is to create OSGi bundles which will run in other OSGi containers, but this approach has some hidden costs.

Firstly, the developer has to decide precisely which packages comprise a given framework. It isn't sufficient merely to import the packages the application code uses, as several enterprise frameworks weave further dependencies into the bytecode of the application when the application is loaded. The developer has to discover, probably by trial and error, which additional implementation packages to import to ensure correct behaviour of the woven application.

Then there is the chore of migrating from one version of a framework to the next where the precise set of packages comprising the framework has changed. The additional packages required for weaving are typically not defined by a public contract and so are subject to change.

Additionally, the resultant package imports don't properly capture the design intent, which makes maintaining or extending the application more difficult in the future.

We really don't want to impose these burdens on our users, so we created some additional SpringSource Application Platform specific manifest headers, Import-Library and Import-Bundle, as convenient ways of expressing dependencies on enterprise frameworks. As you'll see below, these headers are really just syntactic sugar which are expressed in terms of standard OSGi package imports.


The basic syntax is similar to that of other manifest headers:
    Import-Library: <librarySymbolicName>;version=<versionRange>
where <librarySymbolicName> is the symbolic name of the library and <versionRange> is a range of acceptable versions of the library using OSGi version range notation. A library definition specifies the library's symbolic name and version and these together uniquely identify the library to the Platform.

If you are unfamiliar with OSGi version range notation, by far the most commonly used forms are minimum version ranges such as 2, meaning version 2 or later, and half-open ranges such as [2.2.1,2.2.2), meaning any version between 2.2.1 inclusive and 2.2.2 exclusive. If version=<versionRange> is omitted, together with the semicolon delimiter of course, then the default range includes all versions.

For each library import, the Platform selects the library with the given symbolic name and the highest version in the given version range available in the Platform's repository. The Platform then replaces the library import with a set of package imports which match all the packages exported by the bundles of the library. The Platform detects the situation where a bundle imports two or more libraries which export a common package, issues an appropriate log message, and fails to install the importing bundle.

So, for example, the following header imports some version of the Spring Framework library between 2.5.4 inclusive and 2.5.5 exclusive:

    Import-Library: org.springframework.spring;version="[2.5.4,2.5.5)"

Optional Library Import

You can indicate that a library import is optional using the following syntax. Note the special separator := which indicates a directive that modifies the semantics of the manifest header, as opposed to the separator = which indicates a matching attribute, like version.
    Import-Library: <librarySymbolicName>;version=<versionRange>;resolution:=optional

If resolution is not specified, or is specified as mandatory, the bundle containing the import library header will fail to install if there is no library with the given symbolic name and a version in the given range. But if resolution:=optional is specified, the library import will be ignored if no suitable library is available.

So, for example, the following header imports some version of the Spring Framework library from 2.5 onwards, but is ignored if no suitable library is available:

    Import-Library: org.springframework.spring;version="2.5";resolution:=optional

Importing More than One Library

If you need to import more than one library, then specify a comma-separated list of library imports in a single Import-Library manifest header as in the following example:


Import-Bundle is a further convenience for cases where a library would consist of only a single bundle and a library definition is inconvenient to create. The syntax is very similar to that of Import-Library except that it refers to a bundle's symbolic name and version instead of those of a library.

As you would expect, for each imported bundle, the Platform selects the bundle with the given symbolic name and the highest version in the given version range available in the Platform's repository. The Platform then replaces the bundle import with a set of package imports matching the packages exported by the bundle.

So, for example, the following header imports the Hibernate Object-Relational Mapper bundle:


Why not Overload Require-Bundle?

If you are familiar with OSGi, you may be asking yourself why we didn't overload Require-Bundle instead of introducing Import-Bundle.

Well, we wanted Require-Bundle to retain its standard semantics, including the ability to marry together pieces of a split package. But we wanted Import-Library and Import-Bundle to have the same underlying semantics as Import-Package which avoid the complexities of split packages.

We also anticipate that, as the Platform evolves over time, we'll need to add further directives to Import-Library and Import-Bundle which would not be appropriate to add to Require-Bundle.

What Next?

The Platform beta program is in progress and we'll be listening to all feedback on Platform features, including the new manifest headers.

For users who want to take advantage of the Platform's headers, but who need to produce bundles which will run on other OSGi containers, we plan to produce a tool which will replace the Import-Library and Import-Bundle

Get the Spring newsletter

Thank you!

Get ahead

VMware offers training and certification to turbo-charge your progress.

Learn more

Get support

Spring Runtime offers support and binaries for OpenJDK™, Spring, and Apache Tomcat® in one simple subscription.

Learn more

Upcoming events

Check out all the upcoming events in the Spring community.

View all