I’m in Paris at the moment, delivering a training session for a group of people here about the Spring Framework. During such a training students ask a lot of questions. Usually I just answer them but sometimes I have to put them aside to answer them later on.

This time, I thought, why not blog about those questions. So without further ado, here are a couple of questions I got during the Spring training last couple of days:

Can you have multiple BeanFactoryPostProcessors in one context and if so, what about ordering?

As part of our training we always cover ways of extending Spring using for example BeanFactoryPostProcessors. We didn’t discuss the ordering mechanism in general yet, and one of the guys asked about ordering BeanFactoryPostProcessors.

The obvious order the post processors execute would of course be the order in which they’re defined in the XML file, one of the others said. Unfortunately, you can’t rely on the order of the beans defined in a Spring XML file. The order in which they’re defined is not guaranteed to be the order in which they’re executed.

The real solution is in fact quite simple. Spring features an interface called Ordered (it lives in the package org.springframework.core). All of Spring’s BeanFactoryPostProcessors (such as the PropertyPlaceholderConfigurer, that externalizes property values into externally manages resources) implement this interface, implicitly giving it a setOrder property. By setting the order property for each of the post processors, Spring will sort them before they executed ensuring the correct order.

Consider the following example:

The setting of the order property will ensure that the PropertyPlaceholderConfigurer will be given a chance to modify the bean factory before the custom MyOtherPostProcessor, which has been assigned with order value 2.

In Spring 2.0, can you specify multiple return types in a pointcut expression?

In Spring 2.0, we’ve introduced a tighter integration between Spring AOP and AspectJ. One of the most visible enhancements that came out of this is the ability to use the AspectJ pointcut expression language inside Spring AOP. This doesn’t mean Spring AOP has changed much internally; the way you’re configuring it however is changing a bit (although the Spring 1.x way of configuring aspects is still available).

A small sidestep. Historically, within Interface21, Rod Johnson is known for writing awfully long (but really clear class names). Adrian however is also capable of writing really long names; he however does it for methods:

The PointcutParser class features a method called getPointcutParserSupportingSpecifiedPrimitivesAndUsingContextClassloaderForResolution().

So, as Erik told me, In case you want to get pointcut parser supporting specified primitives and using context classloader for resolution, please use that method

Okay, joking aside, the AspectJ pointcut parser makes Spring AOP a lot more usable. During the training in Paris this week, we spend a decent amount of time on all of this, since the guys here are probably going to make heavy use of AOP. The people really appreciated the fact that even before Spring 2.0 is out, we have a really solid set of 2.0 training material for them.

With the pointcut expression language, it’s possible to select methods returning all kinds of types. So the expression execution(String com.interface21..MessageService+.*(..)) selects methods on the MessageSerivce class returning a String. One of the questions that came up was, if it was possible using the AspectJ pointcut expression language to select methods that return void or a String (for example). And fortunately, this is possible:


execution(String || void com.interface21..MessageService+.*(..))


selects all methods on the MessageService class (and derived classes) that accept any number of arguments and return either String or void.

And another question bites the dust :-).

Can you have more than one aop:config tag in one context file?

Short and simple answer: yes you can! I’m not sure though why you would want such a thing. The aop:config tag nicely groups all AOP related functionality together in your context file.

The import tag, does it use Spring Resources?

With Spring, there are several ways of assembling ApplicationContexts. One of those is using the import tag, defined in the beans schema. This import tag has one attribute, called resource. And as the name suggest, yes, the resource attribute indeed uses Spring’s Resource abstraction underneath.

So you can import XML files into other XML files using the following notation:

Okay, that’s it for now. Tomorrow is the last day of the training, so there might be even more questions after tomorrow. We’ve got Spring MVC and Spring WebFlow left on the menu. Usually we do the web-related functionality on day 3 of the 4-day Core Spring training, but for one time, I’ve switched the fourth day with the third, to accommodate for a manager who also wanted to join in for the AOP material.