The Spring Blog
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.
Dear Spring community,
I’m pleased to announce that Spring Web Services 1.5.1 has been released!
This is the first bug fix and enhancement release in the Spring-WS 1.5 series. It fixes all bugs reported since 1.5.0 and introduces various enhancements throughout the framework:
- Introduced a Spring JMS MessageConverter that uses OXM marshallers
- Introduced a Spring MVC View that uses OXM marshallers
- Fixed WS-Security signatures when using WSS4J in combination with SAAJ messages
- Support for timeouts on HTTP transports
- Support for Castor 1.2, see note below
- Airline sample now uses Spring Security
Spring Security 2.0.1 is now available.
Spring Security 2.0.1 provides a number of fixes to the recent 2.0.0 release. It also offers some further improvements in relation to OSGi support, extended namespace configuration, and cryptographically-strong token generation. It is entirely backward compatible with 2.0.0 and can be used as a drop-in JAR replacement.
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.
** 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.
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.
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 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,
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.