Well, it took a lot longer than we initially anticipated, but I'm really pleased to say that the Spring Dynamic Modules project reached its 1.0 milestone today. When I first posted on this topic back in September of 2006 ("Spring OSGi support gaining momentum") the initial specification was just an attachment to an issue against the Spring Framework, and connections to the wider OSGi community were only just beginning to be formed.

Fast forward eighteen months, and Spring Dynamic Modules has become a full-fledged project in the Spring portfolio with committers from SpringSource, BEA, and Oracle. Both BEA and Oracle are using Spring Dynamic Modules to build their own OSGi-based products (see for example "WebLogic Event Server - why we used Spring"), and the Spring Dynamic Modules discussion group has almost 1000 members. The OSGi Alliance itself has formed an Enterprise Expert Group…

We recently hosted a webinar on the theme of "Spring in Production." I promised then to make the recording of the webinar and accompanying slides available on our website. Unfortunately the engineers producing the webinar for us forgot to set the 'record' flag, so I need to re-record the session for you :(. I'm traveling at the moment but I'll try to do that and make it available as soon as I can.

The good news is that there's no need for you to miss out in the meantime. I wrote a white paper on the topic of "Spring in Production" that covers the material from the webinar and more besides…

Dear Spring community,

I'm pleased to announce that the first Spring Framework 2.5 release candidate is available! Spring 2.5 is the culmination of the effort that started as Spring 2.1 milestones, enhancing Spring 2.0 with many new features, such as:

• full Java 6 and Java EE 5 support (JDBC 4.0, JTA 1.1, JavaMail 1.4, JAX-WS 2.0, etc)  
• full-featured annotation-driven dependency injection (including support for 'qualifiers') 
• support for component scanning in the classpath (autodetecting annotated classes) 
• bean name pointcut element in AspectJ pointcut expressions 
• built-in support for for AspectJ load-time weaving (based on the LoadTimeWeaver abstraction) 
• further XML configuration namespaces ("context", "jms") for maximum convenience 
• completely revised framework for integration tests (with support for JUnit 4 and TestNG)
• new annotation-based controller style for Servlet MVC and Portlet MVC
• extended SimpleJdbcTemplate functionality (support for named parameters etc) 
• officially certified WebSphere support (support for the WebSphere 6 UOWManager facility) 
• Spring framework jars are shipped as OSGi-compliant bundles out of the box
• Spring ApplicationContext can be deployed as JCA RAR file (for headless application modules) 
• JCA 1.5 message endpoint management (for Spring-managed JMS and CCI message listeners)
  

Download | Documentation | Changelog 

Particularly worth mentioning are the annotation-based MVC controller style, the JAX-WS support and the TestNG support, all of which are introduced in this release. Furthermore, this release comes in three different distributions, introducing a minimal standard zip and an intermediate with-docs zip.

We recommend upgrading to Spring 2.5 from all previous 2.0.x versions, in order to benefit from the new features as well as from the significant performance enhancements that Spring 2.5 has to offer. Spring 2.5 is designed as a drop-in replacement for Spring 2.0, except for the slightly restructured jar file contents (see the readme file in the distribution).

Note that Spring 2.5 is still compatible with JDK 1.4.2+ and J2EE 1.3+. Java 1.4 users, for example on WebLogic 8.1 or WebSphere 5.1/6.0, are very welcome to upgrade to Spring 2.5 as well! We recommend putting the backport-util-concurrent jar on the classpath when running on Java 1.4, which allows Spring (and hence your applications) to benefit from significant concurrency enhancements.

Juergen Hoeller
Interface21
http://www.interface21.com

You may have seen some of the recent press surrounding the announcement that Interface21 is partnering with Tasktop to create a "Spring Tool Suite". This suite will bring together Spring IDE, the AspectJ Development Tools (AJDT), AspectJ, and Mylyn to create a task-focused approach to the development of Spring-powered enterprise applications. We hope to have a preview of the integrated suite available to share with you at the forthcoming The Spring Experience conference, but in the meantime you'll see many of the improvements flowing into the existing Spring IDE, AJDT, AspectJ, and Mylyn open…

Yesterday GigaSpaces announced the latest release of their Space-Based Architecture, and it's got a new name to go with it too: the GigaSpaces eXtreme Application Platform (XAP). To quote from their press release:

The new release provides a complete middleware platform for managing data, messaging and business logic for applications that require high performance and the ability to scale horizontally across hundreds of machines.

As part of the new product release, GigaSpaces has embraced a much simpler, non-intrusive programming model that allows developers to write their applications in Plain Old Java Objects (POJOs), plain .Net and plain C++ objects. For Java, GigaSpaces is achieving this by supporting the Spring Framework, which is rapidly becoming the de-facto standard in Enterprise Java programming.

Announcements like this are part of a virtuous circle (described for example by Geoffrey Moore in his book "The Gorilla Game") whereby the pervasiveness of the Spring Framework makes it very compelling for vendors to provide Spring Framework integration in their products, which in turn increases the overall value of Spring. This of course helps to make Spring even more pervasive…

Late last year we started talking about the notion of a Spring "release train". The idea behind the release train is that we put out co-ordinated releases of the products in the Spring Portfolio: tested together and working together. You can still pick and choose the pieces you need, but it will be easier to use the various products together when you want to. We're not there yet, but we're on our way.

One of the struggles for us at Interface21 has been that the demand for our support services, training, and consultancy has been so high that we've been working everyone flat out to try and meet it. This has made it hard to get the consistent and predictable product development time we need to pull off something like a release train. That's just one of the many reasons that I'm so excited about the recent announcement of the $10M investment that Benchmark Capital is making in Interface21 (press release…

No, that's not my headline, it's actually the title of a white paper recently published by Open SOA collaboration. To quote from the news announcement accompanying the whitepaper:

"Based upon user feedback, the OSOA Collaboration are publishing a white paper highlighting the powerful combination of the SCA, Spring and OSGi technologies aimed to help Developers simplify the creation and composition of services critical to building applications based on an SOA approach."

The white paper provides a short overview of SCA, OSGi and Spring, and then describes how they can be used together. Quoting from the summary:

"SCA, OSGi and Spring are all useful and powerful facilities for the Java programmer to use. In the new service-oriented world that we are entering, using SCA, OSGi and Spring together provide powerful capabilities for building service implementations from sets of simple Java Beans using few APIs, with managed dependencies, version control and dynamic update capabilities, allied to the capability to compose those implementations with other service components written in Java or in other languages and existing in a distributed network of systems using a range of communication methods.

Simplicity, flexibility, manageability, testability, reusability. A key combination for enterprise developers."

It started out as a small thing. Just a hunch of mine that Spring and OSGi should sit together very well. The idea was that by enabling Spring applications to be deployed in an OSGi runtime, we could bring better modularity, versioning, runtime deployment and update capabilities to Spring applications. It's a project I never really advertised; I just started experimenting, talking to a few people, and writing some early prototype code.

It turns out that a lot of people seem to be interested in Spring and OSGi. We have a collaboration ongoing with representatives from BEA, Oracle, IBM, Eclipse, the OSGi Alliance, and several others to build a shared model of how Spring support for OSGi should look, and how we can make it easy to build enterprise applications on the OSGi runtime. The most recent version of the specification is attached to Spring JIRA issue 1802. Here's a direct link to the specification text…

An article I wrote for the InfoQ site has just gone live: Simplifying Enterprise Applications With Spring 2.0 and AspectJ.

I've heard a number of people saying that "AOP is too hard", or "AOP makes things too complex". In a way this article was written as a rebuttal of those views (hence the title, "Simplifying Enterprise Application Development"). I mean, the whole point of AOP is that you take software that was getting complex and tangled up, and you simplify the implementation by giving each module a single responsiblity again by introducing aspects. And then of course for some…