** 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…

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:

1. Java EE WAR
2. Raw OSGi bundles
3. 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…

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?

Why are web applications in OSGi problematic?

…

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…

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…

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.
…

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…

Spring Security 2.0.0 is now available.

Download | Changelog | Announcement | Web Site

After almost two years of development, Spring Security 2.0.0 is now available for download. This significant new release replaces Acegi Security as the official security module for Spring applications. It offers substantially simplified configuration, and countless other new capabilities including OpenID, NTLM, JSR 250 annotations, AspectJ pointcut support, domain ACL enhancements, RESTful URI authorization, groups, hierarchical roles, user management API, database-backed "remember me", portlet authentication, additional languages, Web Flow 2.0 support, Spring IDE visualization and auto-completion, enhanced WSS support via Spring Web Services 1.5 and much more.

Dear Spring Community,

We are pleased to announce that Spring Web Flow 2.0.0.RC1 is now available. Download | Documentation

2.0.0.RC1 introduces several new features, and fixes all known issues reported against previous milestones.

We recommend upgrading to 2.0.0.RC1 from previous Web Flow 2 milestones. We also recommend Web Flow 1 users begin evaluating their upgrade to Web Flow 2 at this time, as RC1 introduces comprehensive version 2 documentation, as well as a tool for automating the conversion of version 1 flows to the version 2 syntax.

The best way to get started with Web Flow 2 is to evaluate the reference applications included in the distribution and supplement with the reference guide.  Spring Web Flow 2 requires Spring Framework 2.5.3 and Java 1.4 or above. 

Find the new and noteworthy in the 2.0.0 RC1 release below:

2.0.0.RC1 New and Noteworthy

• Introduced the Web Flow 2 reference guide, available in PDF and HTML format. The new guide is written in "quick reference" style with runnable code examples. Read it on-line, or download the printable PDF.

• Added support for upgrading from Web Flow 1 to 2. Included in this distribution is a WebFlowUpgrader tool capable of converting flows from the version 1 syntax to the version 2 syntax. See the reference guide for instructions on how to use this tool

• Added support for flow definition inheritance. With this feature, A flow may extend one or more flows. A flow state can also extend another state. This feature is used to facilitate reuse between flows and states that share a common structure.

• Introduced Spring Portlet MVC support. See the Portlet section of the reference guide and the booking-mvc-portlet and booking-faces-portlet sample applications for examples.

• Formally introduced the new "Spring Javascript" module, included within spring-js-2.0.0.RC1.jar. This module provides a Javascript abstraction framework for applying client-side behaviors such as form validation and Ajax in a consistent manner. It also bundles a ResourceServlet for serving Javascript and CSS from jars (a CSS framework is included as well). The default UI toolkit this framework builds upon is Dojo 1. Spring's JSF integration module called "Spring Faces" builds on spring-js to provide a lightweight JSF component library for form validation and Ajax.

• Added Spring Faces integration with the RichFaces JSF component library. Rich Faces can be used with the Spring Faces component library or used standalone. A sample application illustrating this integration is available in our JIRA system.

• Added a "jsf-booking" reference application that offers a comparsion between a traditional JSF web application and a Spring web application that uses JSF as the UI component model. Compare jsf-booking with booking-faces to see the differences in the architectural approach and implementation. This comparison is particularly relevant to JSF developers interested in learning more about Spring.

• Introduced support for automatic model binding and validation with Spring MVC. This support provides a concise alternative to manual FormAction setupForm and bindAndValidate calls. This support also allows registration of data input Formatters application wide, reducing the need to manually register PropertyEditors on a view-by-view basis in many cases. Support for suppressing data binding for a event such as a cancel button click is provided. Support for invoking validators by convention is provided. See the booking-mvc sample for an example.

• Introduced view scope. View scope is allocated when a view-state enters and destroyed when a view-state exits. The scope is useful for updating a model specific to one view over a series of Ajax requests. It is also the scope used to manage JSF component state.

• Added support for flow message bundles. Create a messages.properties file in your flow's working directory for the Locales you need to support and off you go.

• Introduced configurable view-state history polices. A view state can preserve its history to support backtracking, discard its history to prevent backtracking, and invalidate all previous history to disallow backtracking after a point of no return. See the new 'history' attribute on the view-state element.

• Refined the flow execution snapshotting process. These refinements capture view-state form values on postback to support restoring those values when backtracking. This preserves edits when going back using the browser back button for data stored in flow scope.

• Simplified flow execution testing by allowing you to jump to any state to begin a test case. See the booking-mvc and booking-faces for examples of flow test cases.
  

• Improved booking-mvc as a reference application showing @Controllers together with Flows. A new FlowHandler concept provides a clean bridge between Controllers and Flows, allowing the two types of handlers to interact in a structured manner. Also improved the organization of the reference application Spring configuration to illustrate best practice.