TSS2009: Spring for the Advanced Java Developer

Spring for the Advanced Java Developer

Speaker: Rod Johnson, Creator, Spring Framework; Author, Expert One-on-One J2EE Design and Development and more

Talk covered

• New features in Spring 2.5
• Spring 3.0 themes and road maps

My notes are below. For Rod’s full presentation slides, see here.

Spring 2.5

Comprehensive support for annotation based configuration

• @Autowired
• @Transactional
• @Component, @Service, @Repository, @Controller

Common JEE5 annotations also supported

• @PostConstruct
• @PreDestroy
• @Resource
• @EJB

So can you can now do container config primarily or exclusively via annotations

e.g. @Autowired identifies an injections point where Spring needs to inject a class

You can also now have an annotated DAO with lifecycle annotations

e.g. @Repository

Best practice: use @PostConstruct and @PreDestroy – These should be used instead of the Spring specific InitializingBean and DisposableBean interfaces, with their callback method implementations afterPropertiesSet() and destroy() respectively.

The biggest change in Spring 2.5 is:

Spring NO LONGER requires XML (but still can use it)

You need to use XML only when you need to externalize something

You specify you are using annotations uses

<context:annotation-config>

Or you can use a combo of both, e.g.  you just need to define beans, no constructor args/properties

Or take it to the next level and tell Spring to scan the classpath for suitable classes to auto create, meaning you don’t even need to the bean definitions anymore.

Question: why isn’t this done automatically?

Answer, it would affect existing applications, so need to have backward compatibility

Resolving Dependencies – @Autowired in Details

• @Resource is not considered best practice – too limited
• Can annotate constructors, fields or methods to define injection points AND how they should be created
• Default behavior is Spring’s traditional Autowire By Type
• Annotations make autowiring more useful.
• @Autowired allows you to specify certain fields/methods that are of interest for autowiring.
• Also, you are no longer constrained by setter naming conventions.

However, Autowiring by type can have too many candidates…

Resolution on dependencies by Name – @Qualifier

So, now we can provide hints using qualifiers

@Qualifier annotations

Use if you had more than one instances of a type

e.g.

@Qualifier(“ds1”)

DataSource ds1,

@Qualifier(“ds2”)

DataSource ds2

There is also another strategy for qualification…

Resolution of dependencies by annotation

This idea was taken from Guice

e.g.

@Emea Oderservice emea

@Apac OrderService apac

2 ways to do it…

1 By annotations

So @Emea is used as an annotation for a particular class

Second is using XML

“Association of injection target with anotation: by XML”

This works well where you can’t easily annotate something (e.g. don’t have the source code)

The @Component meta-annotation

*Meta-annotations

– Annotations can annotate other annotations

– Allows extensibility, similar to Java inheritance

*Spring stereotypes

Concept introduced in Spring2.0

Identify cases with a particular purpose

Out of the box, Spring provide several stereotype annotation

• @Service
• @Repository
• @Aspect
• @Controller

Component scanning

• When on, Spring scans the classpath for annotated classes
• Removes the need for XML definitions
• Can co-exist with XML bean definitions

Component scans pros:

• No need for XML (unless you need the greater sophistication XML provides)
• Changes are picked up automatically
• Works great with annotation driven Dependency Injection

But…

• Not a 100% solution – cant do everything with annotations
• Requires classes to be annotated (what if you don’t have source?)
• Need care to not scan an excessive number of packages

Mix&Match

It is all Spring metadata in the end!

Best practices

• Use XML for classes you can’t or won’t annotate e.g. 3rd party components such as data source and Message Queues
• Use annotations and classpath scanning for application objects
• Jump into XML for complex injection behavior, per instance config (classes you’ll reuse in different ways)
• See Spring Web Flow sample application, such as booking-mvc

What if I like XML?

• Externalizing config remains very important
• Options include XML and properties files

XML Blueprint

• Has real value
• whereas using annotations results in important data spread across all over the code
• Spring IDE can help you to visualise everything together

Spring 25 – Servlet MVC

Introduced the Controller model

An annotation approach to the MVC framework

@Controller, @Autowired, @RequestMapping, @RequestParam

So you can put many controllers, if they are related in one class

Best Practices

• Do NOT use old Controller interfaces, SimpleFormController and friends
• Annotation model is simpler
• More concise
• Should be no need to use XML bean definitions for @Controllers

Spring 3.0

• 3.0 requires Java5 or above
• 2.5 used a lot of Java5s capabilities, but it wasn’t a requirement
• Spring Expression Language
• Comprehensive REST support
• Support for Portlet 2.0

Powerful Spring EL Parser

Custom expression parser implementation

Next Generation expression engine inspired by Spring web flow

EL can be used in bean definitions

Can also be used in Component annotations

e.g.

@Value(“#{systemProperties.favouriteColor}”)

private String favColor;

Spring Java Configuration

Annotation-centric approach, but unque

e.g. @Bean annotations

like <bean>

Benefits

• Allows for inheritance (as it is pure Java)
• Refactoring friendly
• Gives central place for bean blueprints

Likely impact:

Provides ability to provide abstract configs – compiler can enforce definitions of missing beans, so great for 3rd parties

It is complimentary rather than competing with annotation approach

Spring 3.0 Roadmap

• 3.0 M3 released at end of March
• 3.0 final expected in June