An Update on Spring 2.0 Final
Spring 2.0 was initially supposed to come out in June/July, why the delay? InfoQ spoke to the Spring team including Rod Johnson, Rob Harrop, Adrian Colyer, and Juergen Holler, to find out what’s happening with the framework and what’s coming up.
1) What is the status of the Spring 2.0 final launch? What’s going on there?
We have just updated our 2.0 release plan after an assessment of status in a number of key areas. The target date for Spring 2.0 final is now scheduled for September 26th, 2006. We will also announce another release candidate (RC4) this week.
Since Spring 2.0 development kicked off at last year’s Spring Experience conference in December 2005, we have received a massive amount of feedback from the community. It has truly been an unbelievable response - users have not only been actively suggesting improvements, they have been performing extensive QA testing across diverse environments. This has led to major improvements to key new features such as the asynchronous JMS capabilities, the JPA support, and the new JSP form tag library.
At present we are working hard to ensure sure Spring 2.0 plays nicely in an OSGi environment, something that is very important to us and our users. In addition, a large amount of effort is being invested in our documentation. The return is evident when you open the 2.0 reference manual and see just how comprehensive the coverage is.
Overall, we have placed extra emphasis on quality and backwards compatibility for this release. We are happy about that decision. Our user base can be assured that moving to Spring 2.0 will be as painless as possible. The release should be 100% backward compatible and serve as a drop-in replacement in existing projects, however complex they may be. That is tough to achieve, but essential for us and our users given the scope of Spring adoption in the enterprise.
2) What are some of the recent JPA changes that have occurred?
The JPA 1.0 spec did not go final until well along in the Spring 2.0 release cycle, and the implementations are only now becoming mature, so we have been working against a moving target. We underestimated the impact of that on our timescales.
However, as with Spring 2.0 overall, we have also ended up offering greater functionality than we envisaged. We have widened the scope of our JPA integration to support the notion of an "extended" persistence context and the injection annotations in the specification. We have received valuable input from a number of leaders in the JPA space including Mike Keith, the co-lead of the specification. We have also done work on value adds that make it easier for users to switch between JPA providers by providing consistent configuration for features that go beyond the spec that every provider offers and every user needs. In general, we have achieved a consistent, easy-to-use model for working with JPA across environments and are very pleased about that.
Technically the JPA support was a challenge because of the byte code instrumentation that is required by the specification. To support that in all environments--including a test environment--we had to build an abstraction layer that could allow instrumentation, then implement and test it across each environment. While the initial driver here was the JPA spec, this opens up exciting possibilities for the future. For example, it means that we can enable AspectJ load-time weaving portably and efficiently, with the ease of use you would expect of Spring.
We have done a lot of productive work with Mike Keith and other members of the TopLink team to ensure that Spring works well with TopLink Essentials. We are also excited about the OpenJPA project and are working with the OpenJPA team to have out-of-the-box integration with OpenJPA by the 2.0 final release. We also provide integration with the Hibernate EntityManager and hope that other JPA vendors will contribute integration with their products or ship it themselves.
3) What about JMS?
Spring's JMS message listener facility has been tested against all major JMS providers and has been significantly improved based on user feedback to be able to adapt to any JMS scenario out there-J2EE or non-J2EE, XA or local transactions, pooled or non-pooled. It now stands as the most flexible JMS message listener facility available, offering unique capabilities for working with native JMS providers and local JMS transactions.
4) What does is it mean to use Spring in an OSGi environment?
OSGi provides an excellent foundation for dividing an application into modules (called 'bundles' in OSGi terminology) with strict visibility rules for types that are visible to a module. It supports concurrent deployment of multiple versions of modules, with clients being bound to the most recent compatible version according to their import specification. OSGi also provides a dynamic environment enabling modules to be installed, updated, started, stopped, and uninstalled at runtime. However, OSGi lacks any means to wire together the components within a module, and only provides basic support (through the declarative services specification) for wiring together services across modules. That is where we come in.
The Spring OSGi support makes it easy to configure a bundle using Spring, with a Spring application context automatically instantiated when a bundle is activated. A new Spring namespace handler for OSGi makes it equally easy to define beans representing OSGi services (and to track the lifecycle of those services), to export beans as OSGi services, and to obtain configuration properties from the OSGi configuration administration service. Spring also transparently manages the context classloader so that enterprise libraries that are not designed for OSGi can continue to be used in an OSGi environment.
In short, Spring-OSGi aims to provide the power of the underlying OSGi framework, with the simplicity and ease-of-use characteristics that have come to be associated with Spring.
5) What are IBM, BEA, and Oracle doing with OSGI and why is it important for Spring to play a part in it?
Many organisations are recognising the value that OSGi can bring to enterprise software. IBM's WebSphere 6.1 is based on an OSGi kernel, for example. Supporting the enterprise space is a new direction for the OSGi Alliance, and a special Enterprise Workshop is being organised to bring interested parties together with a view to forming an expert group. IBM, BEA, and Oracle will all be represented at that event.
IBM, BEA, and Oracle are also collaborating with Interface21 on the Spring-OSGi support. Spring and OSGi are a very natural fit: as OSGi moves towards the enterprise, enabling users to unlock the power of OSGi through Spring is the obvious thing to do.
6) What are some of the thoughts for Spring post 2.0?
We see Spring 2.0 as a strong basis for moving forward, rather than an end in itself. A lot of work has gone into providing a stable platform for the work we will be doing in the next 6-18 months.
One example of that is in the area of AOP. The integration with AspectJ in Spring 2.0 is elegant and extremely powerful. We offer a single programming model for AOP, whether users are using Spring AOP’s proxy-based runtime or AspectJ. Beyond Spring 2.0, we are interested in exploring cases for additional out of the box aspects. We will be building on the load time weaving abstraction we developed for the JPA integration, as it opens up some exciting possibilities such as enabling Spring aspects to be built with AspectJ.
We are also planning further work in the JPA area, such as working with JPA vendors to offer a portable way of offering common functionality that goes beyond the spec, such as a criteria-style API. That is another area where Spring 2.0 is already designed to offer a base for future development.
We will be steadily releasing further ease of use features, such as more XML extension tags to simplify repeated tasks. The experience of using Spring 2.0 is already notably simpler than Spring 1.x, and we are doing ongoing work in that area, especially in the area of web applications.
One major priority for the rest of the year is delivering the full OSGi integration. We have completed the groundwork in Spring 2.0, but the full implementation will follow in 2.1 or 2.2. Once the technical integration is complete we think there will be some exciting benefits for application developers, as well as companies developing server software.
7) How do Spring’s subprojects, Acegi Security, Spring Web Flow, and Spring Web Services fit in with Spring 2.0?
We expect all three of these projects to take advantage of the latest Spring 2.0 capabilities while preserving Spring 1.2 compatibility as far as possible.
Acegi is a solid piece of software and popular with our users. Spring 2.0 particularly provides an opportunity to simplify its configuration so it can reach a wider audience.
Spring Web Flow is a next generation web application development technology people are excited about. It solves the problem of orchestrating multi-step user dialogs better than anything else out there, and the 1.0 final release will set a foundation we expect to position the product well for becoming more general purpose in the future. Version 1.0 is going final in the same timescale as Spring 2.0. The next release candidate (RC4) goes out this week and introduces a custom Spring 2.0 XML schema that simplifies configuration of the flow execution engine by building in defaults.
Spring Web Services is a young project that is really starting to emerge. It builds on Spring to provide support for implementing lightweight document-driven web services in Java. Future versions will take advantage of improvements in Spring 2.0’s web and remoting support.
In general, the Spring Framework core provides a common base of services our own sub-projects also leverage to address more specific domains. We are excited about the new doors Spring 2.0 is opening for these projects, for other emerging projects in the Spring community, and for our end users.
Learn how to apply the latest Spring 2 capabilities at The Spring Experience conference this December.
Interface21, the company behind the Spring Framework, offers Spring-related training, consulting, and support services worldwide.
Download the latest Spring 2.0 release candidate.
TopLink Essentials is the open-source community edition of Oracle's TopLink product and the JPA Reference Implementation.
Open JPA aims to be a fully compliant, enterprise grade open-source JPA implementation suitable for production use.
Get started with the Java Persistence Architecture (JPA) in a Spring environment.
Learn about Message Driven POJOs, asynchronous message listeners executable in a Spring environment with a standalone JMS provider.
Read more about Aspect Oriented Programming with Spring 2.0 and AspectJ.
The OSGi Alliance is an independent non-profit corporation comprised of technology innovators focused on the interoperability of applications based on the OSGi platform.
Criteria API (nice)
This is very nice. Its nice to see Interface21 innovate to what should have been part of the JPA spec. in the first place.