Notes from a session at TheServerSide Java Symposium March 2009
Rod addressed some emerging best practices based around annotation-based application configuration using Spring 2.5 and later.
The emerging best practice is to use the @Autowired annotation rather than @Resource. He demonstrated how to disambiguate bean references with @Qualifier. He also showed how to create your own custom annotations and use them to disambiguate similar types:
@Autowired
public void setOrderServices(@Emea OrderService emea, @Apac OrderService apac) { ... }
@Emea
public class EmeaOrderService implements OrderService { ... }
@Apac
public class ApacOrderService implements OrderService { ... }
(What was unclear to me at the time is whether or not these custom annotations required some definition elsewhere, but I’m not entirely conversant on how annotations work.)
He also spent some time on the @Component meta-annotation, and the concept of stereotypes. Spring comes with several pre-configured stereotypes:
- @Service
- @Repository
- @Aspect
- @Controller
It’s a powerful concept.
So here’s the big question for me. Why are we configuring with annotations now? It doesn’t do away with the need for context XML files. He indeed mentioned the pros and cons for using Spring 2.5 annotations:
Component scanning pros:
- No need for XML (potentially)
- Changes picked up automatically
- Works great with annotation driven injection
- Highly configurable (whatever that means)
Component scanning cons:
- Not a 100% solution (can’t do everything with annotations)
- Requires classes to be maintained
- Need to take care not to scan an excessive number of classes (use filtering)
- Don’t get valuable application blueprints documented in application XML
He makes a decent case for mixing and matching XML configuration with annotation configuration.
The emerging best practices (he says) include:
- Use XML for classes that you can’t or won’t annotate, such as third party components (data sources, message queues)
- Use annotations and classpath scanning for application objects
- Jump into XML for complex injection behavior and per-instance configuration (like injecting lists and maps)
He suggests the Spring Web Flow example application for examples.
He recommends moving away from the old Spring MVC inheritance model in favor of the @Controller stereotype. (Need to go back to his slides for other recommendations.)
The rest of the presentation covered features coming up in Spring 3.0. One nice feature is the ability to embed property value injection with a @Value annotation and a new expression language. Example:
@Value("#{systemProperties.favoriteColr}")
private String favoriteColor;
@Autowired
public void init(@Value("{systemProperties.databaseName") String dbName)
I was happy to see this presentation, because I’ve really been resistant to using annotation based configuration and component scanning. I do like the XML blueprint for an application, and I like having one place to look for how my application is configured. (I even try to avoid using multiple application context XML files, which avoids having to hunt through several files to find my bean configuration.)
Things that happen by magic like autowiring make me a little uncomfortable. He pointed out that the Spring IDE is a good practical solution for actually browsing through your app configuration.