As most of you know, one of the big improvements in Spring 2.0 is the addition of the AspectJ pointcut language and better integration with AspectJ in general. While I think everyone believes that this will be a great benefit in the long run, it has led to some issues. We've found that there are certain behaviors that Spring AOP has always done, that AspectJ has never done.

One of the big issues that cropped up was the behavior of Before advice. If you've used Spring AOP in Spring 1.x you probably know that Spring allows you to change argument values before they are passed to the target…

Spring - here to stay for a long time I visit many clients and speak to even more on a day-to-day basis. This includes existing Interface21 clients as well as companies that are interested in our products and services across Europe. I have noticed a recurring theme in the conversations I am having: Spring is here, and it is here to stay.

Over the last year I have witnessed executive-level decisions that have standardized Spring throughout the fabric of leading Enterprise Java development firms. Just two weeks ago I asked one of my clients - a Java unit manager at one of Europe's largest…

Lately it seems like I've been focusing on creating Spring XML namespaces. It's been a lot of trial and error (both on the XSD and Spring side) to get a good pattern for creating parsers. One of the biggest confusions that I ran into was the AbstractBeanDefinitionParser hierarchy. At this point it isn't documented especially well (but there is a JIRA for it, so it'll be fixed before GA), so I'll give you a rundown of your choices, what they're good for and how to use them.

AbstractBeanDefinitionParser choices

There are three primary BeanDefinitionParsers that Spring provides to help you parse your XML namespaces.

• AbstractBeanDefinitionParser
  • AbstractSingleBeanDefinitionParser
    • AbstractSimpleBeanDefinitionParser

I'm going to start at the most specific and work towards the most general to show how to gain more power when you need it. If you want to skip the examples and see the summary, check here…

Dear Spring Community,

We are pleased to announce that Spring LDAP version 1.1 has been released. This is the first release of the library as a Spring Framework sub project. Download | Documentation | API

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

Hey all!

This is my first post since I joined Interface21 last month. My previous blog is now officially deprecated and I won't be updating it anymore.

So what is the subject of my first post (except to introduce myself)?  Validation logic.  It won't be a walkthrough of how to perform validation in the Spring framework, rather it will discuss a particular bug bear of mine :)

In particular, I would like to discuss exactly what should go into validation logic.  It seems to be a no-brainer answer; "logic to validate the specified data".  OK, that is a no-brainer but read on :). As you know, the Spring framework provides a nice abstraction layer for your validation, via the Errors and Validator interfaces.  In particular the Validator is where you apply your business specific validation rules to your populated domain object.  Spring's excellent binding support is responsible for updating your domain model…

Hello all,

This is just a quick entry to let you know I have officially relocated my biz.blog to here, our new Interface21 team blog.  I'm excited about this group blog serving as the voice of Interface21.  For those of you who know me, you know to expect a different perspective.

I have got some saved drafts I am working on. Watch for new entries that provide insight into the business aspects of Interface21 soon...

Until then, Steven

Dear Spring community,

We are pleased to announce that Spring 2.0 RC3 has been released.  Download | Documentation | Changelog

This third release candidate includes many refinements based on valuable user feedback that we received for the previous release candidates.  With this release, Spring 2.0 final is now just around the corner.

The most significant refinements include:

• Spring 1.2 compatibility has been restored for default-lazy-init="true", with respect to detection of special beans (such as PropertyPlaceholderConfigurers) by type. Alongside, lazy class loading has been reworked to allow for placeholders in class names etc. Strict lazy class loading can still be enforced for special ApplicationContexts.

• Persistence exception translation based on the @Repository annotation is now available for Hibernate3, JDO and TopLink as well, not just for JPA.  Exception translation is now based on the underlying ORM tool's native exceptions as far as possible, with Spring-specific SQLException translation only applying when explicitly specified.

• In our JMS support DefaultMessageListenerContainer features refined resource handling (which works on JBoss 4.0 as well), and is able to recover from a broken Connection or Destination. The caching of JMS resources is now fully configurable, with sensible defaults for both the XA and the non-XA scenario. Furthermore, JmsTemplate reuses cached JMS resources within a JTA transaction.

• Servlet and Portlet Web MVC support a common WebRequestInterceptor abstraction now, which allows Open Session/EntityManager/etc in View interceptors to be reused across Servlet and Portlet environments. As a consequence, all such Portlet-specific interceptors have been dropped in favor of the new generic ones (OpenSessionInViewInterceptor etc).
  

Of course, there are many further refiements in the details. Please see the changelog file (as well as the changelog in JIRA) for details.

Let us know about any remaining issues you might encounter with RC3.  The Spring 2.0 final release is now just around the corner.

Juergen Hoeller,
Lead Spring Framework Development

Of all the new Spring 2.0 features and improvements, I must admit that Message-Driven POJOs are one of my personal favorites. I have a feeling that a lot of other Spring users will feel the same way.

Here I am providing a quick introduction. There is a lot more to show, and I will follow this up with other posts. For now though - this should provide you with enough information to get up and running with some truly POJO-based asynchronous JMS! I hope you are as excited about that as I am ;)

Prerequisites:

You will need the following JAR files on your classpath. I've also listed the versions that I am using (any spring-2.x version should be fine. I just dropped RC3 in there about 2 minutes ago in fact):

• activemq-core-3.2.2.jar
• concurrent-1.3.4.jar
• geronimo-spec-j2ee-managment-1.0-rc4.jar
• commmons-logging-1.0.4.jar
• log4j-1.2.9.jar
• jms-1.1.jar
• spring-2.0-rc3.jar

Setup the Environment

First, we need to setup the environment. I am going to be using ActiveMQ, but the impact of changing a provider will be limited to modifications within this one file. I'm calling this file "shared-context.xml" since as you will see shortly, I am going to be importing these bean definitions for both sides of the JMS communication. Here are the "shared" bean definitions: the connection factory and two queues (one for the requests and one for replies):

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans 
                           http://www.springframework.org/schema/beans/spring-beans.xsd">
	
    <bean id="requestQueue" class="org.activemq.message.ActiveMQQueue">
        <constructor-arg value="requestQueue"/>
    </bean>
 
    <bean id="replyQueue" class="org.activemq.message.ActiveMQQueue">
        <constructor-arg value="replyQueue…

An article I wrote for the InfoQ site has just gone live: Simplifying Enterprise Applications With Spring 2.0 and AspectJ.

I've heard a number of people saying that "AOP is too hard", or "AOP makes things too complex". In a way this article was written as a rebuttal of those views (hence the title, "Simplifying Enterprise Application Development"). I mean, the whole point of AOP is that you take software that was getting complex and tangled up, and you simplify the implementation by giving each module a single responsiblity again by introducing aspects. And then of course for some…