A few weeks ago I blogged about the origins of the name Spring. We also get many questions about the origins of the name Interface21.

For anyone who's read my books or considered the design of Spring, the interface part is hardly a surprise. It plays on both the OO concept of an interface (for which I've always had a deep love) and the notion of the interface to a system. For example, putting a web interface onto an existing green screen system--something I was actually doing when I first thought of the company name.

So far, so good. The real problem is with the numbers.

As with the name Spring, some of the theories are more interesting than the real explanation. So let's start with the theories I've heard regarding the 21 …

I was on site at a customer last week and a question came from the crowd, "Why isn't getConfigLocations() abstract anymore?" After working in front of customers for a while, it becomes rare that you're speechless, and yet I was. To be honest, my first thought was that there was no way the customer could be right. But lo and behold, in revision 1.3 of AbstractSingleSpringContextTests it clearly states that getConfigLocations() is no longer abstract. I hadn't created any new integration tests against 2.0.1, so I hadn't even seen the change.

Surprised by this, I put in an email to Juergen to…

These shots of our venue were taken yesterday (proximity to places like this is one of the perks of Interface21 having an office in Florida).

 

The Majestic Westin Diplomat

Complete with an infinity pool

A lazy river underneath

On beautiful beach-front property

We are incorporating several of these shots into the main conference banners to be draped from the towering ceilings of the Diplomat. Everything is set for a great show. See you at The Spring Experience next week!

In the run up to The Spring Experience I've been busy but I've noticed that Rod's been really active on the blogging front. So in some spare time in airports and on planes today, I've decided to do a little blogging.

One of the biggest balancing acts that we in the Spring community have is to make sure that we stay backwards compatible while still innovating. Part of that innovation is taking advantage of new features and constructs in later versions of Java such as Java 5. Since the 1.2.x branch, we've seen some of this with things like the @Transactional annotation and our JMX auto-detection based on the @ManagedResource annotation. In the end these are great features and have greatly simplified development (at least mine anyway), but they really amount to moving metadata into the code. What we hadn't seen was…

Thanks to our philosophy of pluggability and a lot of hard work in the implementation, the Spring IoC container (like most of the rest of Spring) is extremely flexible.

One point that is often missed is that Spring configuration need not be in XML, although the XML format is by far the most commonly used. Spring has its own internal metadata format in the form of the BeanDefinition interface and subinterfaces. The BeanFactory and ApplicationContext implementations that represent IoC container instances are powered by this Java metadata, and are quite separate from metadata parsing, which is…

If you've followed October's Spring 2.0 release, you will know that one of the big new features was XML extension name spaces: the ability to define new XML elements and attributes that generate Spring metadata, and can be used alongside regular bean definitions. This provides a valuable new extension point and makes Spring configuration both more simpler to use for many repeated tasks and more powerful.

However, there is also a sweet little piece of syntax sugar that you may not have noticed--probably because no one in the Spring team has gotten around to telling you... Having promised myself…

Dear Spring community,

We are pleased to announce that Spring 2.0.1 has been released. Download | Docs | Changelog.

This is the first maintenance release for Spring 2.0, including fixes for most bugs that have been reported since 2.0 final as well as many minor enhancements. This release also introduces OpenJPA support and GlassFish weaving support. Furthmermore, it features redesigned AspectJ support internals and an improved bean definition tooling SPI.

As always, please see the changelog for the details.

If you are new to the Spring 2.0 series, please also see the original Spring 2.0 announcement for more information.

FYI, the Spring 2.0.2 release is scheduled for end of December. Our JIRA road map outlines the issues that are planned to be addressed in that release.

Juergen
-----
Juergen Hoeller
Lead, Spring Framework Development
Chief Architect, Interface21
http://www.springframework.org
http://www.interface21.com

Dear Spring Community,

We are pleased to announce that Spring LDAP version 1.1.1 has been released. This is an update release that adds several new features and fixes a few problems that were in 1.1. Download | ChangeLog | Documentation | API

A summary of the more important changes:

• Added capability to use server-side controls in search.
• DirContextAdapter.getNameInNamespace() now returns the full DN.
• DistinguishedName now supports multi-valued RDNs separated by a '+' sign, like "cn=Rod+sn=Johnson", for example.
• Added lookup methods that take an array of return attribute names.
• Upgraded Spring to 2.0 internally. Spring 1.2.8 is still supported.

About Spring LDAP
Spring LDAP is a Java library for simplifying LDAP operations, based on the pattern of Spring's JdbcTemplate. The framework relieves the user of the burden of looking up and closing contexts, looping through NamingEnumerations, encoding/decoding values and filters, and more.

The LdapTemplate class encapsulates all the plumbing work involved in traditional LDAP programming, such as creating, looping through NamingEnumerations, handling Exceptions and cleaning up resources. This leaves the programmer to handle the important stuff - where to find data (DNs and Filters) and what do do with it (map to and from domain objects, bind, modify, unbind, etc.), in the same way that JdbcTemplate relieves the programmer of all but the actual SQL and how the data maps to the domain model.

In addition to this, Spring LDAP provides Exception translation from NamingExceptions to DataAccessExceptions, as well as several utilities for working with filters, LDAP paths and Attributes.

Spring-LDAP requires J2SE 1.4. J2SE 1.4 is required for building. J2EE 1.4 (Servlet 2.3, JSP 1.2) is required for running the example.

Where to start
Download the distribution from the link above. The distribution contains extensive JavaDoc documentation as well as full reference documentation and a sample application illustrating different ways to use Spring LDAP.

Home
The permanent home of Spring LDAP is at http://www.springframework.org/ldap.

History
Spring LDAP is based on the SourceForge LdapTemplate project. Users of LdapTemplate are advised to switch to Spring LDAP.

Mattias Arthursson & Ulrik Sandberg
Spring LDAP Project Team

I am regularly asked about the origin of the name “Spring.”

The name goes back to late 2002. In November 2002, I published Expert One-on-One J2EE Design and Development. The book was accompanied by 30,000 lines of framework code, which had accounted for a good deal of the year full-time I put into writing the book. (Writing a 750 page book is enough work on its own; writing a substantial framework to go along with it is sheer masochism. It was hard.) Many of the fundamental concepts of the Spring Framework were there: an already capable IoC container, with BeanFactory and ApplicationContext…