Interface21 Team Blog

Using EclipseLink on the SpringSource Application Platform

Fri, 18 Jul 2008 13:56:28 -0700

This week the EclipseLink team announced the release of EclipseLink 1.0. I've been using EclipseLink on S2AP for a while now; in fact, I used EclipseLink when developing our JPA load-time-weaving support. We've yet to upgrade our internal usage to 1.0 - our beta9 was tagged just before the announcement - but I wanted to demonstrate [...]

Developing Rich Web Applications with Spring

Fri, 18 Jul 2008 13:56:28 -0700

I am pleased to announce that Developing Rich Web Applications with Spring, a three-day bootcamp lead by SpringSource engineers on web application development, is now available. This intense, hands-on workshop teaches how to apply the latest versions of Spring Web MVC, Spring Web Flow, Spring JavaScript, and Spring Faces to create rich web applications. It [...]

SpringSource Seminar Day in Central Europe

Sun, 29 Jun 2008 16:07:44 -0700

SpringSource is organizing its first dedicated seminar day in central Europe: the SpringSource Seminar Day in Linz, Austria, on September 8th, 2008. This is a full-day seminar about current hot topics in the Spring portfolio: a rare chance to hear about what's brand-new and upcoming right from the Spring project leads! The agenda is planned [...]

Pumping it dry: $200 a barrel and $25,000 per CPU

Wed, 25 Jun 2008 02:57:57 -0700

When Oracle acquired BEA systems, I and others noted the significance of the loss of the only independent Java middleware vendor. With Oracle’s recent announcement of a price hike for their products, including WebLogic Server, this is no longer a theoretical issue. They have the oil, and they think they have existing customers over a [...]

Running a Spring Batch Job in The SpringSource Application Platform

Fri, 30 May 2008 09:50:10 -0700

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 [...]

Open Source, Open Strategy: The SpringSource Manifesto

Tue, 27 May 2008 17:20:42 -0700

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 [...]

Implementing Enterprise Integration Patterns part 0

Mon, 19 May 2008 13:21:18 -0700

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 [...]

Why should I care about OSGi anyway?

Thu, 15 May 2008 14:21:21 -0700

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 [...]

Portability, Fish and Chips

Fri, 09 May 2008 16:16:28 -0700

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 [...]

Working with SpringSource Application Platform's provisioning repository

Fri, 09 May 2008 02:17:26 -0700

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 [...]

SpringSource Application Platform Manifest Headers

Thu, 08 May 2008 03:19:22 -0700

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.

Import-Library

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-Library: org.foo.p;version="[1,2)",org.bar.q;version="[2,3)"

Import-Bundle

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:

    Import-Bundle: com.springsource.org.hibernate;version="[3.2.6,3.2.7)"

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 syntactic sugar with equivalent standard package imports.

We'll also be discussing the new manifest headers with our colleagues in the OSGi Alliance to determine if there are general requirements which would be appropriate for OSGi to address in the future.

SpringSource Application Platform Deployment Options

Tue, 06 May 2008 17:16:24 -0700

Since we released the SpringSource Application Platform last Wednesday, numerous developers have downloaded the 1.0.0 beta and started taking the Platform for a test drive. As a result, people have begun asking, "How can I deploy my apps on the Platform, and what kind of deployment and packaging options do I have?" Moreover, developers are eagerly requesting to see working samples. In response, the S2AP team will be releasing several sample applications over the coming weeks demonstrating these features and more, but before you get your hands on these samples, I'd like to give you a high-level overview of the deployment and packaging options available in the Platform. After reading this post you'll be ready to hit the ground running with the samples as well as with your own applications.

Overview

As Rob mentioned in his post last week, Introducing the SpringSource Application Platform, the Platform supports applications packaged in the following forms:

Raw OSGi Bundles
Java EE WAR
Web Modules
Platform Archive (PAR)

When you deploy an application to the Platform, each deployment artifact (e.g., a single bundle, WAR, or PAR) passes through a deployment pipeline. This deployment pipeline supports the notion of personality-specific deployers which are responsible for processing an application with a certain personality (i.e., application type). The 1.0.0 release of the Platform natively supports personality-specific deployers analogous to each of the aforementioned packaging options. Furthermore, the deployment pipeline can be extended with additional personality deployers, and future releases of the Platform will provide support for personalities such as Batch, Web Services, etc.

Let's take a closer look now at each of the supported deployment and packaging options to explore which one is best suited for your applications.

Raw OSGi Bundles

At its core, the SpringSource Application Platform is an OSGi container. Thus any OSGi-compliant bundle can be deployed directly on the Platform unmodified. You'll typically deploy an application as a single bundle or a set of stand-alone bundles if you'd like to publish or consume services globally within the container via the OSGi Service Registry. Please note, however, that due to the scoping nature of the PAR format, stand-alone bundles will not be able to consume services across application boundaries. In other words, a stand-alone bundle can not reference the services of modules deployed within a PAR.

WAR Deployment Options

For Web Application Archives (WAR), the SpringSource Application Platform provides support for the following three formats.

Standard Java EE WAR
Shared Libraries WAR
Shared Services WAR

Each of these formats plays a distinct role in the incremental migration path from a standard Java EE WAR to an OSGi-ified web application.

Standard WAR

As Rob has already pointed out, "Standard WAR files are supported directly in the Platform. At deployment time, the WAR file is transformed into an OSGi bundle and installed into Tomcat. All the standard WAR contracts are honoured, and your existing WAR files should just drop in and deploy without change." Support for standard, unmodified WAR files allows you to try out the SpringSource Application Platform on your existing web applications and then gradually migrate toward the Shared Libraries WAR, Shared Services WAR, and Web Module formats.

Shared Libraries WAR

If you have experience with developing and packaging web applications using the standard WAR format, you're certainly familiar with the pains of library bloat. So, unless you're installing shared libraries in a common library folder for your Servlet container, you have to pack all JARs required by your web application in /WEB-INF/lib. Prior to the release of the Platform, such library bloat has essentially been the norm for web applications, but now there is a better solution! The Shared Libraries WAR format reduces your application's deployment footprint and eradicates library bloat by allowing you to declare dependencies on libraries via standard OSGi manifest headers such as Import-Package and Require-Bundle. The Platform provides additional support for simplifying dependency management via the Import-Library and Import-Bundle manifest headers which are essentially macros that get expanded into OSGi-compliant Import-Package statements.

For detailed information on what kind of libraries you already have at your disposal, check out the SpringSource Enterprise Bundle Repository. In addition, Andy Wilkinson will be posting a blog later this week explaining how to make the most of the Bundle Repository within your applications and the SpringSource Application Platform. So stay tuned.

Shared Services WAR

Once you've begun taking advantage of declarative dependency management with a Shared Libraries WAR, you'll likely find yourself wanting to take the next step toward reaping further benefits of an OSGi container: sharing services between your OSGi-compliant bundles and your web applications. By building on the power and simplicity of Spring-DM, the Shared Services WAR format puts the OSGi Service Registry at your fingertips. As a best practice you'll typically publish services from your domain, service, and infrastructure bundles via <osgi:service … /> and then consume them in your web application's ApplicationContext via <osgi:reference … />. Doing so promotes programming to interfaces and allows you to completely decouple your web-specific deployment artifacts from your domain model, service layer, etc., and that's certainly a step in the right direction. Of the three supported WAR deployment formats, the Shared Services WAR is by far the most attractive in terms of modularity and reduced overall footprint of your web applications.

Web Modules

Above and beyond WAR-based deployment formats, the SpringSource Application Platform introduces a deployment and packaging option for OSGi-compliant web applications, the Web Module format. Web modules have a structure similar to a Shared Services WAR and can therefore take full advantage of all three WAR deployment formats. In addition, web modules benefit from reduced configuration for Spring MVC based applications via new OSGi manifest headers such as Web-DispatcherServletUrlPatterns and Web-FilterMappings. For further details on these and other Web-* manifest headers, please consult the Platform's Programmer Guide. Upcoming releases of the Platform will also support web.xml fragments as well as the aforementioned manifest headers.

If you're building a Spring MVC based web application as a web module, you won't need to worry about configuring a root WebApplicationContext or an ApplicationContext for your DispatcherServlet. Based on metadata in your web module's /META-INF/MANIFEST.MF, the Platform will auto-generate an appropriately configured web.xml for you on-the-fly, and your application will use the ApplicationContext created for your web module by Spring-DM. Future releases will add additional support to simplify configuration of Spring Web Flow based web applications as well.

Migration path from WAR to Web Module

The following diagram graphically depicts the migration path from a Standard WAR to a Web Module. As you can see, the libs move from within the deployment artifact to the Bundle Repository. Similarly, the services move from within the WAR to external bundles and are accessed via the OSGi Service Registry. In addition, the overall footprint of the deployment artifact decreases as you move towards a Web Module.

Platform Archives

The final piece of the puzzle is the PAR (Platform Archive) deployment format. A PAR is a standard JAR which contains all of the modules of your application (e.g., service, domain, and infrastructure bundles as well as a WAR or web module for web applications) in a single deployment unit. This allows you to deploy, refresh, and undeploy your entire application as a single entity. For those of you familiar with Java EE, a PAR can be considered a replacement for an EAR (Enterprise Archive) within the context of an OSGi container. As an added bonus, modules within a PAR can be refreshed independently and on-the-fly, for example via the SpringSource Application Platform Tool Suite (register for the beta program and check out the Eclipse tooling support).

Furthermore, PARs scope the modules of your application within the Platform. Scoping provides both a physical and logical application boundary, shielding the internals of your application from any other applications deployed within the Platform. This means your application doesn't have to worry about clashing with other running applications (e.g., in the OSGi Service Registry). You get support for load-time weaving, classpath scanning, context class loading, etc., and the Platform does the heavy lifting for you to make all this work seamlessly in an OSGi environment. If you want to take full advantage of all that the SpringSource Application Platform and OSGi have to offer, packaging and deploying your applications as a PAR is definitely the recommend choice.

Where to go from here

If you haven't already done so, I encourage you to join the beta program and take the SpringSource Application Platform for a test drive yourself.

You'll find up-to-date documentation in the user guide and programmer guide, and if you happen to run into any issues deploying your applications or have recommendations on how we can improve the Platform, please don't hesitate to create a JIRA issue.

And last but not least, be sure to check out upcoming posts on the SpringSource Team Blog to keep abreast of news regarding the Platform and to see working examples including an OSGi-ified Spring PetClinic sample application which has been modularized and packaged as a PAR.

Running Spring Applications on OSGi with the SpringSource Application Platform

Fri, 02 May 2008 08:17:08 -0700

A lot of people have been asking what exactly the SpringSource Application Platform does for Spring applications to make them run well under OSGi, over and above what you can get out of the box with OSGi and Spring Dynamic Modules. Adrian's post yesterday highlighted some of the general issues, now lets look at a few of the details.

The three most challenging aspects of running Spring applications on OSGi are:

Load-time weaving
Classpath scanning
Thread context classloader management

The remaining, but less interesting, issues include: JSP support, TLD scanning, annotation matching and resource lookups. Overall, there was a decent-sized set of issues that needed to be solved to make applications deploy smoothly.

Load-time weaving

Load-time weaving was one of the most problematic features to support in a robust manner. At the basic level, it requires hooking into the Equinox ClassLoader so that standard ClassFileTransformers can be attached and used during the defineClass calls. On top of this, many uses of LTW require access to a throwaway ClassLoader that can be used to inspect types to decide what needs to happen during the weave, without affecting the real ClassLoader.

This base level of support was actually reasonably simple to achieve. The difficulty comes in when weaving is driven by classes in one bundle, but classes in another bundle need to be woven. This is pretty common in enterprise applications where one bundle contains domain entities and another contains types that use a JPA EntityManager. The Platform takes care of this complexity by ensuring that all bundles in an application can be woven with the appropriate ClassFileTransformers.

When you start propagating weaving across to other bundles, you really need to know when to stop. If you simply apply weaving to all bundles, then applications will interfere with each other. The Platform prevents this from happening by explicitly scoping weaving so that it applies only to modules in the application.

Another issue with LTW is that it complicates refresh. When a bundle is refreshed, OSGi will refresh all the bundles that depend on it. This means that, in the example I gave above, refreshing the domain bundle will cause the EntityManager bundle to be refreshed. However, refreshing the EntityManager does not refresh the domain bundle, meaning that weaving is possibly out of sync. The Platform handles this by propagating refresh to other bundles that are affected by weaving.

Classpath scanning

With classpath scanning, the main issue is that Equinox doesn't expose standard jar: and file: resources. The Platform puts an adapter in the middle so that libraries see the resource protocols that they expect. This has a nice side-effect of making a lot of third-party libraries work - it's not just a fix for classpath scanning.

Thread context classloader management

Many third-party libraries use the thread context ClassLoader to access application types and resources. Each bundle in OSGi has it's own ClassLoader, so therefore, only one bundle can be exposed as the thread context ClassLoader at any time. This means that if a third-party library needs to see types that are distributed across multiple bundles, it isn't going to work as expected.

The Platform fixes this by creating a ClassLoader that imports all the exported packages of every module in your application. This ClassLoader is then exposed as the thread context ClassLoader, enabling third-party libraries to see all the exported types in your application.

This is just a small cross-section of the issues that are addressed by the Platform but hopefully it gives you an idea of what the Platform means for Spring Framework users.

Completing the picture: Spring, OSGi, and the SpringSource Application Platform

Thu, 01 May 2008 14:19:00 -0700

** Updated May 2nd with case study :- see the bottom of this post for details **
I'm sure most of you reading this blog will have seen the announcement of the SpringSource Application Platform yesterday. If not, be sure to check out Rob's blog post which describes some of the motivation, programming model, and roadmap.

A couple of common questions are being asked that I'd like to address straight away in this post. After that I'll describe two other exciting announcements that complement the SpringSource Application Platform itself but that didn't grab the headlines yesterday: the SpringSource Enterprise Bundle Repository and the Application Platform tools for Eclipse. Together these complete the story around OSGi-based enterprise application development with Spring.

The question I've heard several times over the last 24 hours is: what's wrong with OSGi - why can't we just use a vanilla OSGi Service Platform (such as Equinox, Felix, or Knopflerfish) instead of the SpringSource Application Platform?

There is absolutely nothing wrong with OSGi.

OSGi is a great foundation and service platform - that's why we and many others have chosen to build upon it. It's proven in a wide range of industries and applications, and underpins applications such as Eclipse and IBM's WebSphere as well as the middleware stacks of several other vendors.

Programming straight to the the OSGi specification APIs lacks some of the qualities we have come to expect for enterprise applications - such as the ability to use dependency injection and create applications that are easily unit and integration testable outside of the container. Programming straight to the OSGi specification APIs also forces you to deal at a relatively low level with the dynamics of the OSGi platform - what do you do when modules and services you depend on are stopped, started, installed, and updated at runtime? But there's no fundamental obstacle here that we weren't able to overcome with the Spring Dynamic Modules project. Applications built using Spring Dynamic Modules can run on any standard OSGi Service Platform, and we test all our builds against Equinox, Felix, and Knopflerfish. We are committed to ensuring that Spring Dynamic Modules and the Spring based programming model remain runtime neutral. That position will not change with the introduction of the SpringSource Application Platform.

There is also absolutely nothing wrong with existing enterprise libraries.

Well, ok. There are some cases that leave a little to be desired, but by and large we know how to make them work for enterprise application development needs.

So what's the problem then?

If OSGi works so well, and existing enterprise libraries are meeting our needs, then where's the problem? The difficulty comes when you try to combine an OSGi Service Platform with a set of existing enterprise libraries that weren't written with OSGi in mind. That's not the fault of OSGi, it's got a great model that provides for excellent modularity, versioning, and operational control. It's not the fault of the enterprise libraries either - they weren't written to run under OSGi. But the very things that make OSGi so attractive break assumptions that the developers of those enterprise libraries made. The modularity model of OSGi for example stops you seeing the private parts of other people's bundles. That's exactly what you want, until you realise that your enterprise library can no longer see your application types. Lots of things can break: from commons logging to jsps, tag libraries to data sources, load-time weaving to component scanning, resource loading to orm mapping. The list goes on… (Yes, you can get many of these things to work when you package your application code and all of the libraries it needs into a single bundle, but that's very much missing the point!).

This is why you see lots of people building on top of OSGi, but very few cases of passing OSGi benefits on into the application programming model (Eclipse RCP is a rare exception). When you build on top of OSGi, but don't necessarily expose that model for end user application development, you can build to the OSGi model and make things work. When you need to provide a platform on which large numbers of existing enterprise libraries can be used it's a different ball game. If we could just throw all that away and start again with libraries written explicitly for OSGi we'd be fine. We've made sure for example that the Spring Framework is fully able to run inside an OSGi Service Platform. But that's not a realistic proposition. Alternatively we could wait for the developers of existing libraries to convert them all to run under OSGi out of the box (as we have done with Spring). But what's the motivation for them to do that unless everyone else does it too? So we seem to be stuck in a chicken-and-egg situation. It's a problem that the OSGi Enterprise Expert Group has spent a lot of time discussing over the past year.
This is the problem that the SpringSource Application Platform solves :- it bootstraps enterprise application development into the world of OSGi by making standard OSGi bundles with standard OSGi semantics work with existing enterprise application libraries.

I'd also like to re-emphasize that the platform is not just about OSGi : the OSGi support is one of the features we're most excited about, but the SpringSource Application Platform is also an excellent server platform for deploying standard war files. We'll describe the benefits the platform offers in such scenarios in later postings.

Hopefully this post has helped to clear up some of the confusion surrounding exactly how the SpringSource Application Platform relates to OSGi. If you've been following along so far, you might have picked up on another lurking problem: it's all well and good to make existing enterprise libraries work under OSGi, but don't you need to turn all of their jar files into OSGi bundles in order to be able to deploy them? Yes you do. And it turns out that's a lot of work if you want to correctly version all of the imports and exports and ensure that you have correct symbolic names etc.. The good news is that for hundreds of commonly used enterprise applications libraries, we've done the hard work for you and made the OSGi-ready versions available in the SpringSource Enterprise Bundle Repository…

SpringSource Enterprise Bundle Repository

The SpringSource Enterprise Bundle Repository is both a repository that can be used from Ivy and Maven, and also an online searchable database of enterprise libraries. You'll find it at www.springsource.com/repository. You can browse for bundles by name, or just type in a search term to find bundles with matching names, exported packages, classes, or resources. You can also see the minimal (satisfying only the required dependencies) and maximal (satisfying as many of the optional dependencies as possible) transitive dependencies of any bundle.

From the FAQ:

"The SpringSource Enterprise Bundle Repository is a collection of open source libraries commonly used for developing enterprise Java applications with the Spring Framework. The repository contains jar files (bundles) and library definition (".libd") files. A library defines a collection of bundles that are often used together for some purpose (e.g. the "Spring Framework" library). There are hundreds of bundles contained in the repository."
The repository meets the following criteria:

Every jar file in the repository is a valid OSGi bundle. Any jar you download from the repository can be deployed as-is into an OSGi Service Platform and the SpringSource Application Platform. It can also be used as a regular jar file outside of OSGi.
Every bundle and library has full version information associated with it. The package export information for a bundle contains version information, and the package import information for a bundle contains full version range compatibility information.
The repository is transitively complete. The mandatory dependencies of any bundle are guaranteed to also be in the repository. Most of the optional dependencies of any bundle in the repository will also be present. The bundles listed in any library definition are guaranteed to be in the repository.
The repository is self-consistent. Before any artefact is uploaded to the repository, we verify that it can be installed, resolved, and started in an OSGi Service Platform (using the same profile as the SpringSource Application Platform) alongside all of the other bundles in the repository.
The repository can be used from Ivy and Maven based builds.

To maintain these guarantees we have put in place a governance model around the publishing of artefacts to the repository. There is a JIRA instance against which you can raise requests for additional libraries to be included and to report any problems (relating to OSGi manifests etc.) with existing published artefacts.

Application Development Tools:

So far we've discussed the Spring-based programming model for developing applications as OSGi bundles, the availability of enterprise libraries to deploy into an OSGi Service Platform, and a runtime (the SpringSource Application Platform) that enables these legacy libraries to work in an OSGi runtime. The missing piece of the puzzle is the developer tools that make the creation of OSGi-based applications easy.

Eclipse already has OSGi development tools built-in. Since every Eclipse plugin is also an OSGi bundle, the Eclipse PDE tools (Plugin Development Environment tools) can be used for OSGi application development. However, the fact that these tools were primarily designed for the development of Eclipse plugins shows through and there are a couple of common frustrations when using them for OSGi application development. One is that the META-INF/MANIFEST.MF file can only be placed at the root of the project - which doesn't work well with build tools such as Ivy and Maven, and the other is that you are restricted to a single target platform (collection of bundles to develop against) for your whole workspace. What *is* great about the PDE tools, and which you really need, is that they build the compilation classpath for your project from the OSGi manifest - so that you don't have differences in classpath and class visibility between compile, test, and runtimes.

Alongside the SpringSource Application Platform we've also released a set of Eclipse plugins (available from the SpringSource Application Platform download page) that makes the development of OSGi applications easier, especially applications targeted at the SpringSource Application Platform. Your META-INF/MANIFEST.MF file can be in any source directory, and the tools build the compilation classpath from the manifest entries. Instead of a single target platform though, you can associate your project with a SpringSource Application Platform server defined to Eclipse (using the WTP facilities). The classpath for your project is then derived from the import statements in your manifest, resolved against other bundle projects in your workspace and the bundles installed in the associated server. You get the exact same interpretation of your classpath and dependencies at compile time as you do at runtime. And of course, the normal "deploy to server" options work too.

Here's how the server looks when it's running inside Eclipse:

And this screenshot shows how the classpath is managed with a "Bundle Dependencies" classpath container. Notice how packages that you have not imported in your manifest file are greyed out to indicate that you can't currently access them.

Even better is how we're able to take advantage of OSGi's modularity. A set of projects (one per bundle) make up your application. When you change anything in the project, an additional incremental builder analyses the resources deltas and does a live update of the running bundle in the SpringSource Application Platform - so you're continually running with the latest code : every time, all the time. That's a great productivity boost and a great development experience.

Case Study

Matt Raible posted a blog entry about his adventures trying to get a Spring web application working under OSGi using Freemarker - without using the SpringSource Application Platform. This seemed like a good challenge application to test out what I said above about making existing enterprise libraries work. The good news is, this application runs very happily on the SpringSource Application Platform. Here are the steps I followed to make it work (total time, about 10 minutes):

Download the zip file from Matt's blog
Run 'mvn'
cp target/mpapp.war to the pickup directory of the Platform
Startup the platform: bin/startup.sh.

I got the following output to the console:

com.springsource.platform.deployer.core.DeploymentException: Unable to satisfy constraints of 'myapp' version '0.0.0':

Cannot resolve: myapp  Unsatisfied leaf constraints:

Bundle: myapp_0.0.0 - Import-Package: org.springframework.osgi.web.context.support; version="0.0.0"

Did you mean: 'org.springframework.osgi.context.support'?

Bundle: myapp_0.0.0 - Import-Package: freemarker.ext.servlet; version="0.0.0"

Did you mean: 'javax.servlet'?

Bundle: myapp_0.0.0 - Import-Package: freemarker.core; version="0.0.0"

Did you mean: 'org.hamcrest.core'?

Bundle: myapp_0.0.0 - Import-Package: freemarker.template; version="0.0.0"

Did you mean: 'org.antlr.tool'?

Bundle: myapp_0.0.0 - Import-Package: freemarker.cache; version="0.0.0"

Did you mean: 'org.apache'?

These are expected messages since I don't have freemarker or the osgi.web.context support bundles installed in the platform.

Go to http://www.springsource.com/repository. Type "freemarker" into the search box, find the one matching entry and click on the link to download it. Copy the downloaded bundle in repository/bundles/usr
Simplify the manifest to point to the new bundles and libraries on the platform. The original manifest looked like this:

Import-Package: javax.servlet,javax.servlet.http,javax.servlet.resources,javax.swing.tree,

javax.naming,org.w3c.dom,org.apache.commons.logging,javax.xml.parsers;resolution:=optional,

org.xml.sax;resolution:=optional,org.xml.sax.helpers;resolution:=optional,

org.springframework.osgi.web.context.support, org.springframework.context.support,

org.springframework.web.context, org.springframework.web.context.support,

org.springframework.web.servlet, org.springframework.web.servlet.mvc,

org.springframework.web.servlet.mvc.support, org.springframework.web.servlet.view,

org.springframework.ui, org.springframework.web.servlet.view.

freemarker, freemarker.cache,freemarker.core,freemarker.template,freemarker.ext.servlet

and I took it down to:

Import-Package: org.apache.commons.logging

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

Import-Bundle: com.springsource.freemarker;version="2.3.12"

When we know you are deploying a web application, the commonly required imports are automatically added at deployment time. Import-Library and Import-Bundle allow you to conveniently refer to libraries and bundles in a single statement. I also deleted the "Bundle-Classpath" entry as the application platform will automatically detect libraries in WEB-INF/lib and add them to the bundle classpath.

I edited web.xml and commented out the context-param declaration since there is no need to use a custom application context type here
Run 'mvn' again, and copy the myapp.war into the pickup directory.
The Application Platform automatically redeployed the application
Point a browser at http://localhost:8080/myapp/ …. SUCCESS!

I think this is a nice demonstration of the value proposition of the platform in smoothing the path of making enterprise libraries work under OSGi.

Introducing the SpringSource Application Platform

Wed, 30 Apr 2008 12:06:07 -0700

After many months of feverish coding, I am pleased to announce the beta release of the SpringSource Application Platform 1.0.

At the beginning of 2007 we began discussing possible alternatives to the monolithic and heavyweight application servers with which Enterprise Java has become synonymous. Customers were looking for a platform that was lightweight, modular and flexible enough to meet their development and deployment needs.

The Spring and Tomcat pairing demonstrates that developers and operators can successfully use a lightweight platform in production. Despite the success of this combination, the lack of modularity and explicit support for non-web applications limits its applicability and flexibility.

We set about building the SpringSource Application Platform to address these requirements and remove these limitations.

At the heart of the Platform is the Dynamic Module Kernel (DMK). The DMK is an OSGi-based kernel that takes full advantage of the modularity and versioning of the OSGi platform. The DMK builds on Equinox and extends its capabilities for provisioning and library management, as well as providing core function for the Platform.

To maintain a minimal runtime footprint, OSGi bundles are installed on demand by the DMK provisioning subsystem. This allows for an application to be installed into a running Platform and for its dependencies to be satisfied from an external repository. Not only does this remove the need to manually install all your application dependencies, which would be tedious, but it keeps memory usage to a minimum.

The DMK itself requires a minimal set of bundles to run, and is configured with a profile to control exactly the set of additional modules that are loaded. For example, the DMK does not require Tomcat to be present, but the default Platform profile includes Tomcat to allow web applications to be deployed. If you want to run a Platform without Tomcat, you can simply edit the profile and it won't be installed. (If you try this - remember that removing web support means that web modules will no longer deploy, so delete the contents of the pickup directory so the platform won't attempt to install the Admin and splash screen applications when it starts.) The default Platform configuration with the admin console installed takes only 15MB of memory.

One frustration I have always had with Enterprise Java is that applications are often shoe-horned into contrived silos, and that explicit support for different application types is lacking. Consider an application for an online store. This application has a web front-end, a message-driven order processing module, a batch-driven stock reordering module and a B2B web service module. Today, many applications like this would be packaged as a WAR or an EAR and the modules would look very similar, with little support for the differences in the module types. Interestingly, many people would refer to this as a web application, rather than an application with a web module.

In the SpringSource Application Platform, applications are modular and each module has a personality that describes what kind of module it is: web, batch, web service, etc. The Platform deploys modules of each personality in a personality-specific manner. For example, web modules are configured in Tomcat with web context. Each module in the application can be updated independently of the other modules whilst retaining the identity of being part of the larger application. Whatever kind of application you are building, the programming model remains standard Spring and Spring DM.

In the 1.0 Platform release we support the web and bundle personalities, which enable you to build sophisticated web applications. Future releases will include support for more personalities as detailed later.

Building Applications

The Platform supports applications packaged in three forms:

Java EE WAR
Raw OSGi bundles
Platform Archive (PAR)

Standard WAR files are supported directly in the Platform. At deployment time, the WAR file is transformed into an OSGi bundle and installed into Tomcat. All the standard WAR contracts are honoured, and your existing WAR files should just drop in and deploy without change.

Any OSGi-compliant bundle can be deployed directly into the Platform, and can take full advantage of on-the-fly provisioning for any dependencies referred to by Import-Package and Require-Bundle.

The PAR format is the recommended approach for packaging and deploying applications for the Platform. A PAR is simply a collection of OSGi bundles (modules) grouped together in a standard JAR file, along with a name and a version that uniquely identify the application. The PAR file is deployed as a single unit into the Platform. The Platform will extract all the modules from the PAR and install them. Third-party dependencies will be installed on-the-fly as needed.

The PAR format has three main benefits over deploying the bundles directly into the Platform. Firstly, it's just easier. An average-sized enterprise application might contain 12+ bundles - deploying these by hand will be far too cumbersome. Secondly, the PAR file forms an explicit scope around all the bundles in the application which prevents applications that use overlapping types or services from clashing with each other. This scope is also used by some advanced features such as load-time weaving to ensure that weaving of one application doesn't interfere with weaving of another. Lastly, the PAR forms a logical grouping to define what modules are part of an application and what third-party dependencies the application has. This grouping is used by the management tools to provide a detailed view of the application. A typical PAR application looks like this:

Dependencies between modules in an application are typically expressed using Import-Package and Export-Package. Dependencies on third-party libraries can be expressed in the same way, but for many libraries this can be error-prone and time-consuming. When using a library such as Hibernate, you will typically have to import more packages than you initially expect. To get around this you could use Require-Bundle, but this has some semantic rough edges such as split packages where a logical package is split across two or more class loaders causing problems at runtime. The Platform introduces two new mechanisms for referring to third-party dependencies: Import-Bundle and Import-Libary. Import-Bundle is analogous to Require-Bundle except it prevents split packages and the other problems with Require-Bundle. Import-Library provides a mechanism to refer to all the packages exported by a group of bundles, for instance all bundles in the Spring Framework, in a single declaration:

Bundle-SymbolicName: com.myapp.dao.jdbc
Bundle-Version: 1.0.0
Import-Bundle: org.apache.commons.dbcp;version="1.2.2.osgi"
Import-Library: org.springframework.spring;version="2.5.4.A"

Here I have a module bundle that depends on the Commons DBCP bundle and the Spring Framework library. The Spring Framework library contains all the bundles needed to use Spring in your application.

Import-Library and Import-Bundle expand under the covers into Import-Package and are therefore consistent with standard OSGi semantics.

The Platform understands the personality of a module, and from this can infer how to configure the module's execution environment. When deploying a web module, all the servlet infrastructure needed for a typical Spring MVC application is created automatically, removing the need to recreate this boilerplate code across applications. In the 1.0 final release, more smarts will be added to the web module personality to support additional technologies such as Spring Web Flow.

Whatever packaging format you choose, the programming model is simply Spring Framework and Spring Dynamic Modules, with the other Spring Portfolio products running on top.

Serviceability

Serviceability was a critical consideration for the whole engineering team. We have spent an inordinate amount of time worrying about the format of log messages and the size of stack traces to make sure that diagnosing problems with your applications is as easy as possible. Any time we find a task that is repetitive and time-consuming we look for a way to automate it or remove it altogether.

To aid with problem diagnosis the Platform has a strong split between log and trace messages. Log messages are intended for end-user consumption and allow you to get access to the most important failure information without having to trawl through gigabytes of trace content. All application failures are displayed and coded in the log output - the codes serving as a convenient way to access knowledge base or support content. To understand why this is so useful, consider the following output from Platform startup:

[2008-04-29 12:12:01.124] main <SPKB0001I> Platform starting.
[2008-04-29 12:12:04.037] main <SPKE0000I> Boot subsystems installed.
[2008-04-29 12:12:06.013] main <SPKE0001I> Base subsystems installed.
[2008-04-29 12:12:07.396] platform-dm-1 <SPPM0000I> Installing profile 'web'.
[2008-04-29 12:12:07.674] platform-dm-1 <SPPM0001I> Installed profile 'web'.
[2008-04-29 12:12:07.721] platform-dm-14 <SPSC0000I> Creating ServletContainer on port 8080
[2008-04-29 12:12:08.036] platform-dm-10 <SPPM0002I> Platform open for business with profile 'web'.
[2008-04-29 12:12:09.405] fs-watcher <SPSC1000I> Creating web application '/admin'
[2008-04-29 12:12:09.652] async-delivery-thread-1 <SPSC1001I> Deploying web application '/admin'

Gone are the pages and pages of output detailing the inner workings of every single type in the startup call chain. Instead, you get messages that actually mean something. Of course, this doesn't mean you can't find out what every type is doing: we still maintain an extensive trace. Indeed, because we split out the most important log messages from trace, our trace can be more verbose because it is intended to be read less often.

Critical failures in the Platform generate a service dump that can be passed to support personnel to aid in the diagnosis process. This dump contains state from all the major subsystems in the Platform and is hooked in via AspectJ to make sure we pick up every possible site where an unchecked Exception can be raised.

The Platform also actively monitors for problems in the JVM and triggers a dump. In the 1.0 release this is limited to deadlock monitoring only, but will include memory, lock contention and CPU contention in future releases.

Roadmap

This beta release is only the start for the SpringSource Application Platform. We have tentatively defined a roadmap to cover the 2.0 release with a focus on five main areas: the Admin Console, middleware integration, additional personalities, clustering and DMK 2.0.

With the Admin Console we want to exploit all the application knowledge that the Platform has, and make this available to the end-user. The Admin Console will allow for detailed inspection of applications starting at the module level and running right down to the bean level. Applications will be linked to the libraries and bundles they depend on, and the Admin Console will provide the ability to upgrade these libraries dynamically. By understanding the different types of beans that an application contains, the Admin Console will provide for detailed insight into application internals and allow for dynamic reconfiguration of certain application components.

To support typical enterprise deployment scenarios, the 2.0 version of the Platform will provide explicit support for common enterprise middleware components such as Oracle, TIBCO EMS and IBM MQSeries. Integration with the Admin Console will allow for connections to these middleware providers to be established in minutes rather than hours or days. Applications will be able to access these connections using the OSGi service registry and Spring DM's <osgi:reference>.

The 2.0 release will introduce additional personalities to cover batch, web services and SOA applications.

Clustering is an important feature for the 2.0 release, with cluster-wide Single System Image (SSI) being the critical piece, and load-balancing and clustered caching being on the roadmap as well. Using the SSI support, administration and deployment operations will be propagated across the cluster. Ultimately, we want to support per-module updates across the cluster, with full cluster-rollback if the upgrade breaks a deployed application.

DMK 2.0 will include improvements to the concurrency subsystem to support large numbers of bundles that change frequently and to support larger numbers of modules with more complex interdependencies. Also included will be updates to the provisioning subsystem and integrated resource management and monitoring for memory, threads, IO and CPU.

What next?

Please download the Platform and try it out. We are keen to hear about your experiences building new applications and deploying existing ones. All feedback, positive or negative, is welcome. We are particularly interested to hear how we can make the process of building and deploying applications easier and more enjoyable.

The binary releases and forums can be found here. Both the user's guide and programmer's guide are available online. We have a JIRA instance set up here.

Today, Portability Matters More Than Ever

Tue, 29 Apr 2008 12:14:03 -0700

Yesterday, I blogged about how Spring helps maximize application portability. Even if the portability problem has been an ongoing topic in enterprise Java land for many years, that blog was timely. Today, Oracle announced that its $6.7 billion acquisition of BEA Systems has closed. There is substantial overlap between the product sets of the two companies, so this is bound to bring uncertainty to the WebLogic and OC4J customer bases. WebLogic and OC4J may both fall into the "J2EE server" category but they are very different products with very different characteristics.

Since many enterprise applications end up integrating very closely with the hosting environment, switching a J2EE server is never a trivial task. Quite on the contrary, it may turn out to cause as much pain as switching an operating system. Common J2EE APIs such as the Servlet API are usually less of a problem, despite subtleties in configuration etc. The real problems usually hide in transaction management setup, resource access semantics, integration with external messaging providers, application-wide authentication and authorization, etc. Even the very heart of J2EE, namely JNDI as lookup mechanism, can cause a lot of issues due to different setup rules, server-specific names for EJB components, etc.

Fortunately, the many WebLogic and OC4J customers who adopted the Spring programming model are in a comfortable position. They are not only enjoying Spring-style productivity, but are well placed to manage any server migration that may lie ahead. The Spring Framework in conjunction with key portfolio products such as Spring Security allows for handling many common concerns within an enterprise application's own boundaries. Environment services are used in typical Spring delegation style, in a more specific fashion than in a standard J2EE scenario. As a consequence, moving to a different hosting environment is usually much less intrusive from the application's perspective.

We also hear from Spring users on WebSphere who appreciate those same portability benefits in the migration scenarios that they are currently facing: between different generations of the WebSphere Application Server itself (5.1 / 6.0 / 6.1 / 6.1 with EE 5 feature packs), but also between the established WebSphere Application Server and the Geronimo-based WebSphere Community Edition (which are very different products under the common WebSphere naming umbrella).

I never thought that I would be in the insurance business - but it is satisfying to see Spring helping developers deal with the changing marketplace.

Web Applications and OSGi

Tue, 29 Apr 2008 11:14:11 -0700

Since the first milestones of Spring Dynamic Modules, requests for running web applications in OSGi started to come in. It has been probably one of the most requested features and no wonder, once 1.0 final was released, web support has been the main focus of the 1.1 branch. I am pleased to report that, with the just released M2, as already hinted by Juergen, Spring-DM supports not just vanilla wars (available since 1.1.0 M1) but also Spring-MVC applications running inside OSGi. In this entry, I would like to briefly discuss the typical OSGi web scenario and Spring-DM's approach. But first,

Why deploy WARs in OSGi?

Easy question: OSGi natively provides versioning, package wiring and hot reloading. Imagine taking advantage of these features within your applications: you can stop embedding libraries under WEB-INF/lib and start sharing them between your web apps, avoid taglibs duplications (while keeping multiple versions running) and update, at runtime, only certain parts of your application. This is especially useful as web applications tend to be tiered and thus subject to a significant number of changes during their life cycle.

Why are web applications in OSGi problematic?

The Servlet specification revolves around the idea of a web container: a runtime environment for web components that provides standard services such as life cycle management (object creation and disposal, thread allocation), concurrency, HTTP request handling and so on. The OSGi platform on the other hand, acts also as a managed environment with its Service Registry, package wiring and versioning (to name just a few). To deal with this problem, the OSGi committee designed, part of the compendium specification, the Http Service.

As a side note, when dealing with two managed environments, one is facing an interesting problem: what deployment model to use? That is which is be the bootstrapping platform and which one embedded? In our case, one can either deploy the OSGi platform as a WAR or deploy the web container (under some form of service), inside the OSGi platform. More about this though, in a future entry.

This optional service provides a simple API for registering Servlets and static resources which are mapped to incoming HTTP requests. In order to have a Servlet serving requests inside OSGi, one must programmatically create the Servlet instance and registered it through the aforementioned API. Further more, the Http service supports only the Servlet 2.1 specification which can be quite inconvenient since filters and listeners (used by virtually all of the web frameworks today) are not available.
Most (if not all) of the solutions available today (that I am aware of), for running web applications in OSGi, rely on the Http Service for their functionality. Some address the problems mentioned above using one of the following techniques (as far as I know):

eliminate the need for code by imposing new or translating existing declarative approaches (such as web.xml) into calls to the Http Service
provide Servlet 2.1+ features by building on top of the 2.1 API (for example a filter can be implemented by decorating a Servlet instance) or by extending the standard API

Both of these methods can be successful and go a long way however, in Spring-DM, we opted for a different, unique approach by:

Integrating directly with the web container

In Spring-DM, the OSGi and container space are bridged: the WARs, deployed as usual to the web container, use the OSGi space for their class path and resource lookups. The main advantage of this approach is that to both the OSGi platform and the web container, nothing major has changed - it is just "business as usual".

With Spring-DM one gets:

full Servlet 2.4/2.5, JSP 2.0/2.1 spec support
availability of the container capabilities (blocking vs non-blocking IO, allocated threads in the thread pool and so on)
complete access to web.xml syntax whether it's about filters, listeners, mapping declaration, security or even jndi references. This is especially useful in cases where the container is integrated with a JTA Transaction Manager or a JMS queue. Note that Spring-DM does no parsing (we figured the container does this a lot better then we can)
container specific configuration files (such as Tomcat's META-INF/context.xml)

All of the above and much more are possible since Spring-DM deploys bundles natively to the chosen web container (currently Apache Tomcat 5.5.x/6.0.x and Jetty 6.1.x+ are supported out of the box). This means that it's the web container that instantiates and manages the web application and thus pretty much everything that the container supports is available to the OSGi bundles.

Though 1.1 is not yet final, I encourage you to give M2 a try. The APIs are pretty much stable and the new features documented (more to come as we approach the GA release) - if you need help, check out the Spring-DM forum (yes, we finally have one) and the mailing list. Additionally, if you happen to be at JavaOne, stop by the SpringSource booth and you will get the answers from the source.

Portability at the Framework Level

Mon, 28 Apr 2008 08:13:48 -0700

Portability is a key factor in the Spring universe. We believe in portability at the framework level: Application components are written against a specific framework (or framework generation), such as Spring 2.5; the framework is then in turn responsible for adapting onto any underlying hosting environment. However, the specific application framework is above and distinct from the hosting environment. A brand-new framework version may be deployed onto an established generation of the hosting platform, as long as the fundamental capabilities of the environment are sufficient. This approach differs significantly from the traditional approach of baking component frameworks into the deployment platform itself, where the environment supports a specific version of the framework only - and an intended update of the framework requires an update of the entire platform.

The current Spring Framework generation, 2.5, features explicit support for a wide range of deployment environments. The common Spring programming model applies to all those platforms, with application code typically referring to common framework APIs and specific third-party APIs only. Of course, the actual runtime capabilities differ widely, so the actual services applicable to your application components may differ as well. Here is a list of typical hosting environments:

J2EE 1.3 Application Servers

Spring 2.5 still supports J2EE 1.3 servers (such as WebSphere 5.1 and WebLogic 8.1) as far as possible. Since those servers usually run on JDK 1.4, obviously annotation support and other Java 5+ goodies won't be available. However, the basic Spring programming model and all the Spring 2.5 support goodness around it is fully available, as are many popular third-party libraries for which Spring integration code is provided out of the box (e.g. Hibernate 3.2, Quartz 1.6).

Close integration with server facilities such as the Servlet 2.3 container, the JTA subsystem, server-provided JDBC and JMS resources etc is straightforward. This can easily be achieved through corresponding configuration, with application components being transparently wired through Spring's dependency injection and AOP capabilities. For example, message listeners can be managed as Spring beans; the corresponding configuration takes into account that the JMS version on a J2EE 1.3 server is limited to 1.0.2, adapting accordingly.

J2EE 1.4 Application Servers

The mainstream deployment environment for Spring applications these days is a J2EE 1.4 server, simply because of the widespread availability of J2EE 1.4 products. Many such servers (e.g. WebSphere 6.1 and WebLogic 9.2) run on JDK 1.5, so the full power and flexibility of Spring's Java annotation support is available on those platforms - even if the native APIs and component models of those servers do not provide dedicated Java 5 support. Of course, if the server platform is limited to JDK 1.4 (like on WebSphere 6.0), then Spring is limited to JDK 1.4 as well - fortunately, with a lot of goodies still being available.

Spring 2.5 provides in-depth support for J2EE 1.4 APIs and common server extensions. This includes Servlet 2.4, JSP 2.0 and JAX-RPC 1.1, as well as JMS 1.1 and JCA 1.5. Spring's JMX support also plays very nicely with the J2EE 1.4 provided JMX support in the server environment - easy to configure through Spring 2.5's "<context:mbean-export>" element. Spring can autodetect the specific server's JTA capabilities through the "<tx:jta-transaction-manager>" element; this includes automatic support for WebSphere's UOWManager API and WebLogic's JTA extensions, if applicable. As a further common extension, Spring may delegate to a CommonJ WorkManager (on WebSphere and WebLogic) or a JCA WorkManager (on GlassFish and JBoss) in order to have asynchronous tasks managed by the hosting environment, with the corresponding thread pool configured in the server's console.

Java EE 5 Application Servers

A central theme behind the Spring Framework 2.5 release was comprehensive support for Java EE 5 APIs. Spring 2.0 already featured full-fledged support for the Java Persistence API (JPA). Since Spring 2.5, this is completed through the addition of JAX-WS support (in the "remoting.jaxws" package), explicit support for EJB 3 access (transparently through "<jee:local-slsb>" and "<jee:remote-slsb>"), and JTA 1.1 support (autodetected by "<tx:jta-transaction-manager>") as well as JSF 1.2 support (through SpringBeanFacesELResolver). Furthermore, Spring provides support for the JSR-250 Common Annotations and common JAX-WS, JPA and EJB 3 annotations in Spring-managed bean components (through "<context:annotation-config/>"); this is consistent with the support for those annotations in JSF 1.2 managed beans and EJB 3 session beans.

The primary Java EE 5 product that is popular among Spring users is Sun's GlassFish V2 - already out there for two years. More recently, WebLogic 10 and Geronimo 2.0 joined the group of fully certified Java EE 5 servers, with previous (J2EE 1.4 compatible) generations of those servers still being very popular as well. Spring 2.5 also supports J2EE 1.4 servers with early support for specific Java EE 5 APIs: e.g. WebSphere 6.1 with its JAXB/JAX-WS and JPA/EJB3 feature packs, as well as JBoss 4.2 with its JPA/EJB3 support.

Servlet containers a.k.a. web application servers

A very common deployment environment for Spring is Tomcat, typically in its 5.5 or 6.0 generation. Jetty proves to be quite popular as well, as does Caucho's Resin. The latest generations of those products support Servlet 2.5 and JSP 2.1, i.e. the Java EE 5 level of web container specifications. Spring 2.5 happily runs on all of those servlet containers, providing full application container services within each Java EE web application (WAR file).

Typical setup choices in such an environment include native JDBC transactions and native Java 5 thread pooling. However, Spring - as the open framework that it is - also supports embedding a dedicated JTA transaction coordinator product (e.g. Atomikos or the Geronimo Transaction Manager), or any other third-party middleware. Furthermore, Spring provides full JPA container support in such an environment, allowing for "Java EE level" JPA support in a plain servlet container.

Servlet containers typically allow for full control over the underlying JVM. This can be leveraged in a Spring environment on such a container, e.g. through the unlimited use of AspectJ load-time weaving (which faces limits in a traditional Java EE environment) or through choosing Java 6 (whereas most Java EE servers are limited to a Java 5 platform). Note that Spring 2.5 explicitly supports Java 6 environments, allowing for the use of JMX MXBeans, JDBC 4.0, JAX-WS 2.1 etc!

Custom environments - plain or OSGi based

Beyond Java EE oriented environments, Spring is also very well suited for custom environments on a Java basis. This includes plain JVMs bootstrapped from the command line, possibly integrated with corporate management infrastructure. Such "simple" processes are often used for headless systems that operate in the background, for example message-processing backbones. Spring provides comprehensive framework services for such environments, including component lifecycle management, declarative transactions, and message listener management. While such an architecture is not often talked about, some pretty interesting systems at the heart of large enterprises are implemented that way.

In recent times, OSGi is becoming more and more of an obvious choice for such environments. OSGi provides foundational deployment and runtime services that constitute a great match for the requirements of modular enterprise systems. In such a setting, Spring manages application components within each OSGi bundle, whereas the OSGi platform provides overall management of all deployed bundles. With the upcoming Spring Dynamic Modules 1.1, even web application scenarios on an OSGi basis are becoming as straightforward as they need to be for mainstream usage. Spring on OSGi is a very promising combination that is only starting to show the full breadth and depth of its power!

The same model in any kind of deployment environment

Spring essentially brings its common programming model to any kind of Java-based deployment environment - actually, not just a programming model but a comprehensive configuration model too. This common framework is not limited to "compliant" hosting environments; it can be deployed onto existing platforms as well - runtime platforms that never expected to support this specific framework (or in fact any specific framework) in the first place. Spring redefines the notion of "component portability" to span more hosting environments than Java EE was ever (and will ever be) intended for, with the component model and central framework services being completely independent from specific hosting environments and specific deployment units.

An important benefit of such an arrangement is that it allows the framework and the hosting environment to evolve independently - in particular, a brand-new framework version can be deployed onto an established hosting environment. Spring focuses on application components and configuration convenience; the hosting environment focuses on the generic management of deployment units and shared services. If such a deployment platform happens to be integrated into your corporate environment already, you can preserve the investment while still taking full advantage of the latest application framework innovations… If, on the other hand, new innovations in terms of deployment platforms emerge, Spring allows you to take immediate advantage of those without fundamental changes in the programming model.

Switching between different hosting environments should have as little impact on application components and application configuration as possible, even when switching between different deployment models. This is a central element in the Spring vision, and we're more committed than ever to live up to that promise! From traditional J2EE servers to OSGi-based deployment environments - the Spring Framework brings a lot of commonality to all those environments, while at the same time deeply integrating with relevant platform services in order to get maximum benefit from the specific environment that you chose. Whichever platform you are running on - you may be sure that the Spring Framework is at your full disposal!

The Conference Season Rolls On

Wed, 23 Apr 2008 23:23:44 -0700

Yesterday I gave the opening keynote at the JAX conference in Wiesbaden, Germany. JAX is one of Europe’s largest Java conferences, with over 2,000 attendees. The topic was The Future of Enterprise Java, and I expanded on the themes of my recent blog of predictions, going into more detail about the implications of Java EE 6 and the future of the application server.

I’ve uploaded the slides, which include 8 predictions for an interesting period in the evolution of enterprise Java. This is the first time I've referred to Joseph Stalin, Monica Lewinsky and Monty Python in the same presentation.

JAX was an enjoyable experience overall, with excellent speakers from both Europe and North America and great questions from attendees. The SpringSource booth looked great as always, and it was good to see so many attendees. And, of course, German beer tastes as good as ever!

This seems to be the most active time of year for conferences. In the last few weeks I’ve spoken at QCon in London and the ServerSide in Vegas, and I have several more conferences coming up:

JavaOne. I’ll be speaking on Spring 2.5 (I’m giving the session twice, as there is so much interest), Ben Alex will take about Spring Security and Dave Syer about Spring Batch. SpringSource will have its biggest ever presence at JavaOne. Come to our booth to meet the ultimate Spring experts, and see demos of SpringSource Tool Suite, SpringSource Application Management Suite and other SpringSource Enterprise technologies.
JAOO Sydney (June 2-3): I’ve spoken several times at the Sydney JUG (the first time, nearly 10 years ago, about JSP 0.92 IIRC) and the Sydney Spring Users Group, but this is the first time I’ll have spoken at a conference in Sydney. It’s exciting to see a major conference coming to Sydney.
SpringOne in Antwerp, Belgium (June 11-12). With all the recent releases in the Spring Portfolio, this should be a great show.
Jazoon, in Zurich (June 23-26). I’m giving a keynote, again on the big picture for the industry.

I hope to see you at at least one of these events!

Spring Security 2.0 Final Release: No More Dead Fairies

Thu, 17 Apr 2008 01:21:19 -0700

Spring Security 2.0 has been released. This is a major step forward for the Spring Portfolio. Spring (Acegi) Security is already the Java platform's most widely used enterprise security framework, with over 250,000 downloads on SourceForge and over 20,000 downloads per release. Through making it so much simpler to use, this release will undoubtedly take adoption to a new level.

I'm particularly pleased about this release for a number of reasons:

It's a great thing for the Spring community. It's (a lot) simpler to use, as well as more powerful. It puts the most powerful enterprise Java security solution within the reach of many more users, pretty much eliminating the hurdles to adoption. See this tutorial for an example of just how much easier it makes it to secure a typical web application. The proliferation of XML bean definitions is a thing of the past.
It's a continuation of the work of Spring 2.x, through applying the power of a custom XML namespace to enable aggressive defaulting, while still allowing for customization.
Like Spring 2.5, it exhibits the current Spring Portfolio trend toward radical reduction in the need for XML.
It's a proof of the value of the SpringSource business model. Our revenue model enables us to invest more than ever in creating open source software. Without being able to hire both Acegi/Spring Security creator Ben Alex and the other major committer, Luke Taylor, this release either wouldn't have occurred or would have been much less extensive.
It's good for the fairy kingdom.

Acegi/Spring Security creator Ben Alex and Luke Taylor have done a great job. Ben will be talking about Spring Security at Java One next month. If you'll be in San Francisco then, it will be a great opportunity to hear about the new features and get a chance to talk to the guy behind the product.

Download here.

Runtime Error Analysis in the SpringSource Tool Suite

Mon, 14 Apr 2008 15:21:10 -0700

Three weeks ago, the SpringSource Tool Suite was released. Christian, in charge of this product blogged about it already and we also have a webinar available for those of you that want to get up to speed with all of the functionality it currently offers. In this entry, I wanted to highlight the runtime error reporting functionality specifically.

When I'm programming, sometimes, the console window shows dozens of stack traces due to some error I've caused. Sometimes, I'm lucky and the stack trace looks familiar. If so, then the problem is probably easy to solve. Sometimes however, the information you need is buried so deep inside all those stack traces, that figuring out what the real problem is takes a while.

With the introduction of the SpringSource Tool Suite, we've started to build up a online knowledge base that includes resolutions for common problems you might encounter. Using the knowledge base, you no longer have to browse through pages and pages of exception stack trace information. Instead clicking a simple button will run a query over the knowledge base and if possible cause is found, you automatically get relevant information that will help you solve your particular problem. The quick screencast below should give you some insight into the functionality. Note that the full screen functionality of blip.tv works fairly well, so in case the fonts are a bit small in some parts of the screen cast, using the full screen mode solves this.

We have just started out filling the knowledge base and with the release of the tool suite, it'll probably contain a wealth of errors already. But obviously, the knowledge base cannot hold a resolution for every problem you might encounter. That's why we are constantly adding information about potential errors ourselves, but also allow you to add particular error conditions with suggested solutions. Authoring tools are available directly inside the IDE, so you don't have to bother about using some kind of proprietary XML format. All content submitting by you (and other developers) will periodically be reviewed and released as an update to the knowledge base. In a next screen cast, I'll highlight this functionality.

I'm am really excited about this particular feature of the SpringSource Tool Suite as it will help me get my errors out of the way much quicker than in the past. If you're interested in reviewing the SpringSource Tool Suite, please visit the product page on our web site where currently, you can download a beta after having registered. On that page, we also have a longer webinar available in which Christian Dupuis explains the SpringSource Tool Suite in much more detail.