In my last entry, I walked you through several enhancements in Spring 3 for web application development. A number of you expressed interest in a follow-up entry focused on Ajax remoting. Spring 3 provides a lot in this area to take advantage of. Read on, and I'll walk you through it.

Spring and Ajax Overview

For the purposes of this article, when I say Ajax, I'm talking about the web browser's ability to communicate with a web server asynchronously using JavaScript. On the server-side, Spring provides the programming model for defining web services, including services consumed by JavaScript clients. On the client-side, nobody rolls their own Ajax framework these days, either. Most use an established JavaScript framework such as jQuery or Dojo…

After our mad dash to the final release of Spring Roo 1.0.0 on New Year's Eve, many users have asked for an introductory screencast.

In this 5 minute screencast you will see how to:

• Develop a simple "contact manager application" using the Roo shell
• Import and edit the project our free IDE, SpringSource Tool Suite (STS)
• Run the Roo-provided integration tests in STS
• Modify the application and understand ITD round-trip support
• Deploy to your IDE's web container
• Use the scaffolded web user interface
• "Push-in refactor" to move source code between Java source files and ITDs
• Remove Roo from the project

Interested? Just click the image below and enjoy...

If you'd like to learn more about Spring Roo, please feel free to visit this link:

• http://www.springsource.org/roo

We're pleased to an announce the release of Spring Security 3.0.1.

This is a minor bugfix release, following on from the recent 3.0.0 release. Please see the changelog for a list of issues which have been addressed.

Download | Changelog | Reference Manual | FAQ

At the start of May 2009 we announced we were working on a new approach to joint compilation for mixed Java/Groovy projects in Eclipse. We are pleased to now announce the final release of Groovy-Eclipse v2.0.0, based on that new technology. During the months of development we have rebased (and almost entirely rewritten) version 1 of the Groovy-Eclipse plugin, with the goal of offering first class Groovy support in the Eclipse IDE, comparable to the experience Java developers have in Eclipse.

The most important new features that Groovy-Eclipse 2.0.0 provides are:

• a new approach to compiling joint Groovy-Java code that does not require a stub compiler
• advanced and extensible content assist
• vast speed and memory improvements over previous releases
• debug support
• deep integration with the Java Development tools

Also, over 380 bugs have been…

Today we will be releasing version 2.0 of the dm server. This represents a major milestone for the project, and for enterprise application development with OSGi in general. I’m delighted to now be able to reveal the next step in the dm Server journey: we have submitted a proposal at Eclipse.org to continue development of the dm Server as part of the Eclipse RT top-level project. The Eclipse nickname for the project is Virgo.

Quick links:

• Virgo proposal document at Eclipse.org
• Virgo community forum

What does this mean for users of dm Server?

The move to Eclipse.org has a number of practical implications for users of dm Server:

• Project hosting, home pages, forums, and downloads will all be moved to Eclipse.org infrastructure
• The license will change from the current (largely) GPL license, to the Eclipse Public License (EPL)
• It will be much easier for other organizations and community members to get involved in the ongoing development of Virgo

The combination of the license change and community hosting at Eclipse.org opens the codebase to a much broader set of users and developers.

The follow-on release of dm Server will be developed and released from Eclipse.org.

Why is SpringSource making this change?

The dm Server represents a significant amount of intellectual property (IP) and has been in full-time development for over 2 years. Why would SpringSource move this project to Eclipse.org?

We set out with a vision to make modular application development a…

As Adrian mentioned, today is the day for dm Server 2.0 and I'm delighted to announce that dm Server 2.0 is now available. Thank you for all of the feedback that we've had during the development of 2.0, it's helped to shape it into what we believe is a big step forward for enterprise OSGi. We're now looking forward to the next steps on the journey at Eclipse.org.

There's a lot of great stuff in the 2.0 release. Here's a brief overview:

• dm Shell - we've added a brand new shell in 2.0, that's available both in-process and remotely over ssh. It provides extensive support for managing a dm Server instance and its deployed artifacts.
• Admin console - the admin console has been extensively overhauled in 2.0. It provides, among other things, support for managing and deploying artifacts, examining diagnostic dumps, and examining the bundle wiring both in the live system, and at the time of a resolution failure.
• Plans - dm Server 2.0 introduces support for plans which are powerful alternative to 1.0's PARs for deploying modular applications. A plan can be used to reference all of the artifacts that comprise your application, optionally making the application atomic to tie the child artifact lifecycles together, and scoped to isolate the application from other applications deployed in the same dm Server instance.
• Provisioning - dm Server's always had excellent provisioning support and in 2.0 it's got even better. In addition to the automatic provisioning of bundles based on the needs of the installed applications that was available in 1.0, dm Server 2.0 provides support for provisioning plans, PARs, and configuration from both local and remote repositories.
• Web support - dm Server 2.0 builds upon 1.0's Web support and embeds the Tomcat-based reference implementation for the OSGi Web Container specification, allowing users to deploy vanilla WAR files with all their dependencies in WEB-INF/lib, and Web Application Bundles that import their dependencies via OSGi manifest metadata. The web container is configurable using the standard Tomcat server.xml.
• User region - dm Server 2.0 introduces a user region which isolates the dm Kernel from user-installed applications. Among other things, this simplifies administration as it allows users to focus on user application artifacts and their dependencies without having to deal with those of the kernel as well.
• Spring 3.0 - like many others, we've been tracking the Spring 3.0 milestones and release candidates, and dm Server 2.0 now packages Spring 3.0 final. If you'd prefer to use dm Server 2.0 with a different version of Spring, it can easily be configured to do so.
• Hot deployment - in addition to support for deployment via the admin console, artifacts can also be deployed to dm Server by copying them into the pickup directory, either in archive or exploded form.
• Running as a service - dm Server can now be run as a Windows service or as a Unix background process.
• Logging - as in 1.0, dm Server's logging support is available via SLF4J. In 2.0, the backend has been replaced with LogBack, making it extensively configurable by modifying dm Server's config/serviceability.xml file with a rich set of appenders available out of the box.
• Equinox 3.5 - dm Server 2.0 embeds Equinox 3.5, the reference implementation of OSGi 4.2.

Continuing the Spring 3.0 "simplification series" started by Keith and Chris, I would like to provide a quick overview of simplifications in scheduling and task execution enabled by Spring 3.0.

I will be walking through a basic sample application that you can checkout from the spring-samples Subversion repository. It has been designed to be as simple as possible while showcasing both annotation-driven and XML-based approaches to scheduling tasks in Spring 3.0.

Let's begin with the annotation-driven approach. You can run it directly via the main() method in AnnotationDemo. If you take a look…

We're delighted to announce the general availability (GA) of Spring Roo 1.0.0.

Spring Roo is a next-generation rapid application development tool for Java developers. With Roo you can easily build full Java applications in minutes. It differs from other tools by focusing on:

• Higher Java productivity: Try the ten minute test and see for yourself.
• Stock-standard Java: Roo uses the Java APIs and standards you already know and trust.
• Usable and learnable: Roo features an extremely high level of usability and an advanced shell.
• No engineering trade-offs: Roo has no runtime portion and does not impose any CPU, RAM or disk storage cost.
• Easy Roo removal: Roo can be easily removed from a user project in under five minutes.

This release follows some eight community releases (A1, A2, M1, M2, RC1, RC2, RC3, RC4) and extensive feedback. Before reaching Roo 1.0.0 we already had over 1,000 forum posts and some 500 Jira issues logged. There's already been dozens of conference and JUG presentations on Roo, several third-party add-ons and there's…

I'm very excited to announce that Bundlor 1.0.0.RC1 is now available. There have been numerous changes to Bundlor since the M6 release including additions to detection and warning criteria as well as improvements to the ANT and Maven configurations.

This milestone marks feature-complete status for the 1.0.0 release. Baring any major issues, this candidate will be released as 1.0.0.RELEASE shortly.

Detection and Warning Criteria

Bundlor now detects Java types in the following locations:

• Java Types
• Spring Context Files
• Blueprint Service Configuration Files
• Web Application Files
• Contained JARs
• JPA Configuration Files
• Hibernate Configuration Files
• JSP Files
• Log4J Configuration Files
• Static Resources

Bundlor also scans the its generated manifest for the following issues and generates warnings based on them:

• Unlikely Import Version Ranges
• Importing of Exported Packages
• Manifest from Signed JAR
• Imports Unversioned
• Exports Unvesioned
• Missing Bundle-SymbolicName
• Missing Manifest-Version

Standardized and Simplified Configuration

One of the most glaringly bad parts of Bundlor up until the RC1 release was the inconsistency of features and configuration across the various front ends (command-line, ANT, Maven). RC1 has unfortunately had to change the configuration parameters of all of these but the end result is consistency and in many cases simplification of Bundlor's configuration.

Please see the Bundlor documentation for the configuration options for your…