Since the introduction of Spring dynamic laguage support in Spring 2.0 it has been an attractive integration point for Groovy, and Groovy provides a rich environment for defining Domain Specific Languages (DSL). But the examples of Groovy integration in the Spring reference manual are limited in scope and do not show the features in Spring that are targeted at DSL integration. In this article I show how to use those features and as an example we add bean definitions to an existing ApplicationContext with a Groovy DSL from the Grails distribution.
The Spring Blog
By popular demand, the Spring Framework Maven artifacts are now being uploaded to the Spring Snapshot Maven Repository. You can find details about all of the Spring Portfolio Maven repositories in my previous post but I’ll reprint the details for the Spring snapshot repository here.
The Spring Snapshot Maven Repository is located at http://s3.amazonaws.com/maven.springframework.org/snapshot. Using this repository requires you to add an entry to the <repositories/> element in your POM. It should look like this:
We’re changing our name. This week, Interface21 will become SpringSource.
As we have built the company, Interface21 has earned a reputation for exceptional products, thought leadership, outstanding people, professionalism and top quality support and services. As we continue to deliver all of those things, we believe that changing our name will help our company bring them to a wider audience.
When I founded Interface21 in 2004, I had to pick a name. I believed Spring to be the future of enterprise Java, and “Interface21” reflected those feelings—the framework for the 21st Century. Now we’re well into the 21 Century. Spring has proven to be more successful than I could have dreamed, and has become a de facto standard for enterprise Java. It’s also growing in popularity on the .NET platform. Millions worldwide have downloaded Spring Portfolio products. All the major Spring committers work here.
Spring Web Flow 2.0 M2 has just released. I am particularly excited about this release because it sets the foundation we need to realize the bold vision we have for our community for the future. In this entry, I’ll explain what that vision is, and exactly what this foundation will enable. I’ll also go into detail about the architecture of Web Flow 2.0, and compare it to the 1.0 version.
The Spring Web Flow 2.0 Vision
* UPDATE: The vision above was updated on 1/11/08 after considering large amounts of feedback from the Spring community since The Spring Experience 2007. Based on that feedback, Spring Web Flow 2.0, scheduled to release in March 2008, will remain focused on the orchestration of controlled navigation and application transactions in a web application, usable as a complement to Spring MVC in an action-based MVC environment and JavaServerFaces in a component-based environment. When used with JSF, Spring Web Flow 2.0 can power an entire JSF-based web application as a “black box” or can be mixed with standard JSF navigation handlers that implement free-navigation requirements. 2.0, therefore, will be an evolutionary release adding first-class support for JSF and Ajax, supporting Java 1.4+, and providing full backwards compatibility with the SWF 1.0 flow definition language.
Spring 2.5 introduces an approach for writing annotated Web MVC controllers, which we haven’t been blogging about much yet… I’ll take the opportunity to give you an overview of what Spring MVC is really about these days.
Spring MVC is essentially a request dispatcher framework, with a Servlet API variant and Portlet API variant. It operates very closely within its hosting environment - either Servlets or Portlets. Think about Spring MVC as providing foundational facilities and conveniences on top of the Servlet/Portlet container: e.g. flexible request mappings, separation between controller processing and view rendering phase, data binding, basic JSP tag libraries that complement the JSTL, etc. The building blocks of sophisticated HTTP request processing.
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. This white paper is available right now for download.
Last night I attended a New England Java User Group (NEJUG) meeting where Reza Rahman presented a "comparative analysis" of EJB 3 and Spring. Reza is one of the authors of EJB 3 in Action. I enjoyed meeting Reza and respect him for presenting what may be considered a controversial topic. Also I appreciate that he did attempt to address pros and cons for both EJB 3 and Spring. Nevertheless, I feel compelled to clarify a few points that were not wholly accurate in his coverage of Spring and which led me (and other attendees) to believe the presentation was motivated by a bias toward EJB 3. To be fair, unlike a fixed specification version, Spring is constantly evolving and some of the things that I will point out here are new features. On the other hand, some are Spring 2.0 features that have been available for more than a year. I personally believe that a "comparative analysis" must account for the up-to-date feature set of the latest stable version of the products being compared. I think it goes without saying that I might be a bit biased as well, but my motivation here is to provide a wholly objective response so that the presentation could perhaps be revised to reflect a more 'apples-to-apples' comparison. I will provide brief responses to 10 "themes" of the presentation.
Several users have asked whether we are committed to Spring Java Configuration, and how it sits with the annotation configuration option introduced in Spring 2.5. The answer is yes, we are committed to Java Config; and these two approaches are not mutually exclusive.
These two configuration approaches are quite different: the @Autowired annotation in the Spring Framework configures components using annotations in business objects, while Spring Java Config takes a unique approach of externalizing the annotations in dedicated configuration classes. Neither of these approaches is uniquely right or wrong, and they are compelling for different circumstances. There is even no reason that both couldn’t be used in the same application.
As some of you will have noticed already, Spring 2.5 RC1 has finally been released on Monday and is waiting for you to give it a test drive! Spring 2.5 is in many ways the release that completes Spring 2.0’s mission: providing the most flexible and most comprehensive configuration model for both Java 1.4 and Java 5. Spring 2.5 focuses on particularly comprehensive support for Java 5, introducing various further annotations options. I’d like to take the opportunity to point out the unifying themes behind this release:
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 source projects.