Configuration Enhancements in Spring 3.1
Chris Beams
SpringSource, VMware
Rossen Stoyanchev
SpringSource, VMware
ROSSEN STOYANCHEV
YOU
time machine
Spring 1.0
<beans/><beans>
</beans><beans>
<bean id="foo" class="com.foo.Foo"/>
</beans><beans>
<bean id="foo" class="com.foo.Foo"/>
<bean id="bar" class="com.foo.Bar">
<property name="foo" ref="foo"/>
</bean>
</beans><beans>
<bean id="foo" class="com.foo.Foo"/>
<bean id="bar" class="com.foo.Bar">
<property name="foo" ref="foo"/>
</bean>
<bean .../>
</beans><beans>
<bean id="foo" class="com.foo.Foo"/>
<bean id="bar" class="com.foo.Bar">
<property name="foo" ref="foo"/>
</bean>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
</beans><beans>
<bean id="foo" class="com.foo.Foo"/>
<bean id="bar" class="com.foo.Bar">
<property name="foo" ref="foo"/>
</bean>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
</beans><beans>
<bean id="foo" class="com.foo.Foo"/>
<bean id="bar" class="com.foo.Bar">
<property name="foo" ref="foo"/>
</bean>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<bean .../>
<import resource="more-beans.xml"/>
</beans>"Spring beans XML"
Spring beans XML
- simple
- general purpose
- flexible
But...
Spring beans XML
- verbose
- not type-safe
- special tooling
Spring 2.0
<namespace:*/>e.g.
<tx:annotation-driven/>
<aop:aspectj-autoproxy/>
<jee:jndi-lookup/>
<util:list/>"Spring XML namespaces"
Spring XML namespaces
- concise
- powerful
- easier to use
But...
Spring XML namespaces
- opaque
- non-extensible
- difficult to write your own
Spring 2.5
@Autowired@Component<context:component-scan/>"Annotation-Driven Injection"
Annotation-Driven Injection
- really concise, convenient
- now widely used
- especially for MVC
@Controllers
But...
Annotation-Driven Injection
- can't wire up third-party code
- ambiguities can arise (enter
@Qualifier) - still requires xml to bootstrap
I mean, if you've got this
package com.win;
@Component
public class TehAwesome {
@Autowired
public void setStuff(Stuff stuff) { ... }
}I mean, if you've got this
package com.win;
@Component
public class TehAwesome {
@Autowired
public void setStuff(Stuff stuff) { ... }
}... then this is kind of ironic, right?
<context:component-scan base-package="com.win"/>(we'll get back to that in a bit)
Spring 3.0
@Configuration@Bean(quick refresher)
bean definition
@Configuration
public class AppConfig {
@Bean
public QuoteService quoteService() {
RealTimeQuoteService quoteService = ...;
return quoteService;
}
}bean definition
// @Configuration classes =~ <beans/> documents
@Configuration
public class AppConfig {
@Bean
public QuoteService quoteService() {
RealTimeQuoteService quoteService = ...;
return quoteService;
}
}bean definition
@Configuration
public class AppConfig {
// @Bean methods ~= <bean/> elements
@Bean
public QuoteService quoteService() {
RealTimeQuoteService quoteService = ...;
return quoteService;
}
}bean definition
@Configuration
public class AppConfig {
@Bean
public QuoteService quoteService() {
RealTimeQuoteService quoteService = // instantiate
return quoteService;
}
}bean definition
@Configuration
public class AppConfig {
@Bean
public QuoteService quoteService() {
RealTimeQuoteService quoteService = ...;
// configure
return quoteService;
}
}bean definition
@Configuration
public class AppConfig {
@Bean
public QuoteService quoteService() {
RealTimeQuoteService quoteService = ...;
return quoteService; // object managed by Spring
}
}bean definition
@Import(OtherConfig.class) // =~ <import/>
@Configuration
public class AppConfig {
@Bean
public QuoteService quoteService() {
RealTimeQuoteService quoteService = ...;
return quoteService;
}
}bean definition
@Import(OtherConfig.class)
@Configuration
public class AppConfig {
@Autowired QuoteSource quoteSource; // from OtherConfig
@Bean
public QuoteService quoteService() {
RealTimeQuoteService quoteService = ...;
return quoteService;
}
}bean definition
@Import(OtherConfig.class)
@Configuration
public class AppConfig {
@Autowired QuoteSource quoteSource;
@Bean
public QuoteService quoteService() {
RealTimeQuoteService quoteService = ...;
quoteService.setQuoteSource(quoteSource); // inject
return quoteService;
}
}bootstrap and use
public class Main {
public static void main(String... args) {
ApplicationContext ctx =
new AnnotationConfigApplicationContext(AppConfig.class);
QuoteService quoteService =
ctx.getBean(QuoteService.class);
System.out.println(quoteService.currentValue("AAPL"));
}
}bootstrap and use
public class Main {
public static void main(String... args) {
// bootstrap the Spring container
ApplicationContext ctx =
new AnnotationConfigApplicationContext(AppConfig.class);
QuoteService quoteService =
ctx.getBean(QuoteService.class);
System.out.println(quoteService.currentValue("AAPL"));
}
}bootstrap and use
public class Main {
public static void main(String... args) {
ApplicationContext ctx =
new AnnotationConfigApplicationContext(AppConfig.class);
// retrieve the bean we want to use in type-safe fashion
QuoteService quoteService =
ctx.getBean(QuoteService.class);
System.out.println(quoteService.currentValue("AAPL"));
}
}bootstrap and use
public class Main {
public static void main(String... args) {
ApplicationContext ctx =
new AnnotationConfigApplicationContext(AppConfig.class);
QuoteService quoteService =
ctx.getBean(QuoteService.class);
// use the bean however desired
System.out.println(quoteService.currentValue("AAPL"));
}
}"Java Configuration"
Java Configuration
- type-safe, object-oriented
- can configure any component
- complete programmatic control
- no special tooling required
But...
Java Configuration
- no equivalent to
<namespace:*/> - xml still required for tx mgmt, aop, etc
- no support in TestContext framework
back to the future
Spring 3.1
Environment API
PropertySource API
<beans profile="dev"/>
@Profile("dev")
nested <beans/>
c: namespace
testing support
"TestContext Framework"
TestContext Framework
- Since Spring 2.5
- Eases integration testing with Spring
- Support for JUnit and TestNG
@RunWith(SpringJUnit4ClassRunner.class)@ContextConfiguration2.5
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("app-context.xml")
public class MyTest {
@Autowired MyBean bean;
@Test
public void testXyz() {
}
}2.5
@RunWith(SpringJUnit4ClassRunner.class)
// ApplicationContext will be loaded from app-context.xml
@ContextConfiguration("app-context.xml")
public class MyTest {
@Autowired MyBean bean;
@Test
public void testXyz() {
}
}2.5
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("app-context.xml")
public class MyTest {
@Autowired MyBean bean; // injected from app-context.xml
@Test
public void testXyz() {
}
}2.5
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("app-context.xml")
public class MyTest {
@Autowired MyBean bean;
@Test
public void testXyz() {
// assertions against bean
}
}3.1
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes=AppConfig.class)
public class MyTest {
@Autowired MyBean bean;
@Test
public void testXyz() {
// assertions against bean
}
}3.1
@RunWith(SpringJUnit4ClassRunner.class)
// ApplicationContext will be loaded from AppConfig
@ContextConfiguration(classes=AppConfig.class)
public class MyTest {
@Autowired MyBean bean;
@Test
public void testXyz() {
// assertions against bean
}
}3.1
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes=AppConfig.class)
public class MyTest {
@Autowired MyBean bean; // injected from AppConfig
@Test
public void testXyz() {
// assertions against bean
}
}TestContext Framework
- Fully updated for Spring 3.1
- Support for
@Configuration,@Profile
- Much more on testing at Sam's and Rossen's talk on Friday at 10:15
- Updated TestContext reference documentation
- Testing with
@Configurationclasses blog post
@Enable*
@Enable*
(and friends)
e.g.
@EnableTransactionManagement
@EnableAspectJAutoProxy
@EnableLoadTimeWeaving
@EnableScheduling
@EnableAsync
@EnableWebMvc
@ComponentScanSimple.
I mean, if you've got this
package com.win;
@Component
public class TehAwesome {
@Autowired
public void setStuff(Stuff stuff) { ... }
}I mean, if you've got this
package com.win;
@Component
public class TehAwesome {
@Autowired
public void setStuff(Stuff stuff) { ... }
}... then this is kind of ironic ...
<context:component-scan base-package="com.win"/>I mean, if you've got this
package com.win;
@Component
public class TehAwesome {
@Autowired
public void setStuff(Stuff stuff) { ... }
}... but this makes a lot more sense.
@ComponentScan("com.win")and if you've got this
package com.win;
@Repository
public class WidgetRepo {
@Transactional
public void add(Widget widget) { ... }
}and if you've got this
package com.win;
@Repository
public class WidgetRepo {
@Transactional
public void add(Widget widget) { ... }
}... then why do this ...
<tx:annotation-driven/>and if you've got this
package com.win;
@Repository
public class WidgetRepo {
@Transactional
public void add(Widget widget) { ... }
}... when you could do this?
@EnableTransactionManagementExample
Example
@EnableScheduling(Trivial) Example
@EnableSchedulingsome component
package com.startup;
public class ChatterBox {
public void saySomething() {
System.out.println(randomWord());
}
}some component
package com.startup;
public class ChatterBox {
@Scheduled(fixedRate=1000)
public void saySomething() {
System.out.println(randomWord());
}
}some component
package com.startup;
public class ChatterBox {
// (@Scheduled has been
@Scheduled(fixedRate=1000) // around since Spring 3.0)
public void saySomething() {
System.out.println(randomWord());
}
}some component
package com.startup;
public class ChatterBox {
// "hey Spring, call this
@Scheduled(fixedRate=1000) // method every second"
public void saySomething() {
System.out.println(randomWord());
}
}configuration
package com.startup.config;
@Configuration
public class Config {
@Bean
public ChatterBox chatterBox() {
return new ChatterBox();
}
}configuration
package com.startup.config;
@Configuration
@EnableScheduling
public class Config {
@Bean
public ChatterBox chatterBox() {
return new ChatterBox();
}
}configuration
package com.startup.config;
@Configuration
@EnableScheduling // look for and process @Scheduled
public class Config {
@Bean
public ChatterBox chatterBox() {
return new ChatterBox();
}
}configuration
package com.startup.config;
@Configuration
@EnableScheduling
public class Config {
@Bean
public ChatterBox chatterBox() {
return new ChatterBox(); // saySomething() method
} // called once per second
}configuration
package com.startup.config;
@Configuration
@EnableScheduling // ok, so what does this do?
public class Config {
@Bean
public ChatterBox chatterBox() {
return new ChatterBox();
}
}EnableScheduling.java
package org.springframework.scheduling.annotation;
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Import(SchedulingConfiguration.class)
@Documented
public @interface EnableScheduling {
}EnableScheduling.java
package org.springframework.scheduling.annotation;
@Import(SchedulingConfiguration.class) // this is the key =>
public @interface EnableScheduling {
}SchedulingConfiguration.java
package org.springframework.scheduling.annotation;
@Configuration
public class SchedulingConfiguration {
@Bean(name=SCHEDULED_ANNOTATION_PROCESSOR_BEAN_NAME)
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
public ScheduledAnnotationBeanPostProcessor sabpp() {
return new ScheduledAnnotationBeanPostProcessor();
}
}SchedulingConfiguration.java
package org.springframework.scheduling.annotation;
@Configuration
public class SchedulingConfiguration {
// it's just registering the @Scheduled bean
// post processor on your behalf
public ScheduledAnnotationBeanPostProcessor sabpp() {
return new ScheduledAnnotationBeanPostProcessor();
}
}moving parts
@Importnow supported at annotation level@Enable*is just a naming convention@Configurationclasses shipped out of the box
design goal
- Build on existing concepts
- "
@Configurationall the way down"
but what about...
- transparency
- extensibility
- flexibility
but what about...
- transparency ... check
- extensibility
- flexibility
but what about...
- transparency ... check
- extensibility ... ?
- flexibility
but what about...
- transparency ... check
- extensibility ... ?
- flexibility ... ?
(Not-so-trivial) Example
(Not-so-trivial) Example
@EnableWebMvcthrow to Rossen here
Spring MVC Configuration
(Quick Refresher)
(1) Default Configuration
- I.e. blank
<name>-servlet.xml DispatcherServlet.propertiesHandlerMapping,HandlerAdapter.. and other types to instantiate by default- Add own type .. turns off default types
Default Config Experience
- Intentionally minimalistic
- Fairly neutral
- Flexible
- Can be verbose for common tasks
(2) MVC Namespace
- Minimize boilerplate for @MVC
- Targets the 80% use case
- More opinionated
- Serves as starting point
MVC Namespace Experience
- Does a number of useful things
- Minimizes boilerplate
- Transparent .. ?
- Flexible .. ?
What's Behind...
<mvc:annotation-driven />- Find
BeanDefinitionParser - Read meta-data code
- How to customize?
BeanPostProcessor works.. not obvious!
Ease-of-use vs. Control
- A good starting point is important
- But transparency is key in MVC config
- So is flexibility
(3) MVC Java Config
(Spring 3.1)
- Designed with preivous experiences in mind
- Match MVC namespace capabilities
- More transparent
- More flexible
Many copy+paste AnnotationMethodHandlerAdapter config not seeing it overlaps with the config from <mvc:annotation-driven />
MVC Java Config Example
(Spring 3.1)
// Equivalent to <mvc:annotation:driven/>
@EnableWebMvc
@Configuration
public class WebConfig {
}MVC Java Config Example
(Spring 3.1)
// Equivalent to <mvc:annotation:driven/>
@EnableWebMvc // <-- What's behind ?
@Configuration
public class WebConfig {
}@EnableWebMvc
@Retention(RetentionPolicy.RUNTIME)
@Import(DelegatingWebMvcConfiguration.class)
@Target(ElementType.TYPE)
public @interface EnableWebMvc {
}@EnableWebMvc
@Import(DelegatingWebMvcConfiguration.class)
public @interface EnableWebMvc {
}Load MVC Java Config in web.xml
<!-- 1. Change ApplicationContext type -->
<context-param>
<param-name>contextClass</param-name>
<param-value>
org.springframework.web.context.support.
AnnotationConfigWebApplicationContext
</param-value>
</context-param>
<!-- 2. Point to package with @Configuration classes -->
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
org.example.somepackage
</param-value>
</context-param>Built-in Customizations
- Implement
WebMvcConfigurer - Or extend
WebMvcConfigurerAdapter - Simple, discoverable config API
- Matches MVC namespace
Customization Example
@EnableWebMvc
@Configuration
public class WebConfig extends WebMvcConfigurerAdapter {
@Override
protected void addFormatters(FormatterRegistry registry) {
// ...
}
@Override
public void addInterceptors(InterceptorRegistry reg){
// Equivalent to <mvc:interceptors>
}
@Override
public void addViewControllers(ViewControllerRegistry reg) {
// Equivalent to <mvc:view-controller>
}
}Beyond The Common Case
WebMvcConfigurertargets the 80%- A good starting point
- Like the MVC namespace
- Transparency .. ?
- Flexibility .. ?
Once again the ease-of-use vs. control issue exceptin this time not a dilemma
See Provided Config
- Inspect
WebMvcConfigurationSupport - The config imported via
@EnableWebMvc - Class javadoc lists created beans
- Or read
@Beanmethods
Easier to read is relative to reading BeanDefinitionParser code with the MVC namespace
Switch To Advanced Config
- Remove
@EnableWebMvc - Extend
WebMvcConfigurationSupport - Override the same methods as in
WebMvcConfigurer - Also override any
@Beanmethods!
Advanced Config Example
@Configuration
public class WebConfig extends WebMvcConfigurationSupport {
@Override
public void addInterceptors(InterceptorRegistry reg){
// Equivalent to <mvc:interceptors>
}
@Override
@Bean
public RequestMappingHandlerAdapter
requestMappingHandlerAdapter() {
// Create or let "super" create and customize
// RequestMappingHandlerAdapter ...
}
}@Enable*
benefits
- easy to see what's going on
- easy to write your own
- scales smoothly from simple to sophisticated
"Java Configuration"
- (completed)
Java Configuration (3.1)
- completes the vision
- can configure all major container features
- mix and match styles as desired
But...
But... ?
No buts.
No buts.
- can be adopted incrementally
- but can go all the way
- which means...
XML IS OVER!
XML IS OVER!
for dependency injection
XML IS OVER!
for enabling features of the Spring container
XML IS OVER!
for Hibernate integration, too
Hibernate 4 support
- Spring 3.1 RC1 builds against Hib 4.0.0.CR4
- 3.1 GA will sync with 4.0 Final
- new orm.hibernate4 packaging
Familiar?
<bean id="sessionFactory"
class="org.sfwk.orm.hibernate3.LocalSessionFactoryBean">
<property name="dataSource" ref="myDataSource"/>
<property name="mappingResources">
<list>
<value>Person.hbm.xml</value>
<value>Account.hbm.xml</value>
</list>
</property>
<property name="hibernateProperties">
<value>
hibernate.dialect=org.hibernate.dialect.HSQLDialect
</value>
</property>
</bean>Or even
<bean id="sessionFactory"
class="org.sfwk.orm.hib3.AnnotationSessionFactoryBean">
<property name="dataSource" ref="myDataSource"/>
<property name="annotatedClasses">
<list>
<value>com.foo.Person</value>
<value>com.foo.Account</value>
</list>
</property>
<property name="hibernateProperties">
<value>
hibernate.dialect=org.hibernate.dialect.HSQLDialect
</value>
</property>
</bean>Or even
<bean id="sessionFactory"
class="org.sfwk.orm.hib3.AnnotationSessionFactoryBean">
<property name="dataSource" ref="myDataSource"/>
<property name="annotatedClasses">
<list>
<value>com.foo.Person</value> <!-- again the irony -->
<value>com.foo.Account</value>
</list>
</property>
<property name="hibernateProperties">
<value>
hibernate.dialect=org.hibernate.dialect.HSQLDialect
</value>
</property>
</bean>We can do better than that.
@Bean
public SessionFactory sessionFactory() {
return new LocalSessionFactoryBuilder(dataSource())
.addAnnotatedClasses(Person.class, Account.class)
.buildSessionFactory();
}LocalSessionFactoryBuilder
- Extends Hibernate's own Configuration class
- only in the new orm.hibernate4 package
Also...
standalone Hibernate exception translator
@Bean
public SessionFactory sessionFactory() {
return new LocalSessionFactoryBuilder(dataSource())
.addAnnotatedClasses(Person.class, Account.class)
.buildSessionFactory();
}
@Bean
public PersistenceExceptionTranslator exTranslator() {
return new HibernateExceptionTranslator();
}XML IS OVER!
XML IS OVER!
and not just Spring XML
JPA
persistence.xml
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="..."
xsi:schemaLocation="..."
version="2.0">
<persistence-unit name="sample">
<jta-data-source>java:/DefaultDS</jta-data-source>
<properties>
<property name="hibernate.dialect"
value="org.hibernate.dialect.HSQLDialect"/>
</properties>
</persistence-unit>
</persistence>say goodbye.
@Bean
public LocalContainerEntityManagerFactoryBean emf() {
LocalContainerEntityManagerFactoryBean emf =
new LocalContainerEntityManagerFactoryBean();
emf.setDataSource(dataSource());
emf.setPersistenceXmlLocation(
"classpath:META-INF/persistence.xml");
return emf;
}@Bean
public LocalContainerEntityManagerFactoryBean emf() {
LocalContainerEntityManagerFactoryBean emf =
new LocalContainerEntityManagerFactoryBean();
emf.setDataSource(dataSource());
emf.setPersistenceXmlLocation(
"classpath:META-INF/persistence.xml"); // no more!
return emf;
}@Bean
public LocalContainerEntityManagerFactoryBean emf() {
LocalContainerEntityManagerFactoryBean emf =
new LocalContainerEntityManagerFactoryBean();
emf.setDataSource(dataSource());
emf.setPackagesToScan("com.win.entity");
return emf;
}@Bean
public LocalContainerEntityManagerFactoryBean emf() {
LocalContainerEntityManagerFactoryBean emf =
new LocalContainerEntityManagerFactoryBean();
emf.setDataSource(dataSource());
// scan classpath for JPA @Entity types
emf.setPackagesToScan("com.win.entity");
return emf;
}XML IS OVER!
and not just Spring XML
web.xml
web.xml
<web-app>
<servlet>
<servlet-name>dispatcher</servlet-name>
<servlet-class>
org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/spring/dispatcher-config.xml
</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>dispatcher</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<web-app>Gone.
- (if you've got Servlet 3)
equivalent
public class WebInit implements WebApplicationInitializer {
@Override
public void onStartup(ServletContext container) {
XmlWebApplicationContext ctx =
new XmlWebApplicationContext()
ctx.setConfigLocation(
"/WEB-INF/spring/dispatcher-config.xml");
ServletRegistration.Dynamic dispatcher =
container.addServlet(
"dispatcher", new DispatcherServlet(ctx));
dispatcher.setLoadOnStartup(1);
dispatcher.addMapping("/");
}
}even better
public class WebInit implements WebApplicationInitializer {
@Override
public void onStartup(ServletContext container) {
AnnotationConfigWebApplicationContext ctx =
new AnnotationConfigWebApplicationContext()
ctx.register(DispatcherConfig.class);
ServletRegistration.Dynamic dispatcher =
container.addServlet(
"dispatcher", new DispatcherServlet(ctx));
dispatcher.setLoadOnStartup(1);
dispatcher.addMapping("/");
}
}WebApplicationInitializer
- Builds on Servlet 3's ServletContainerInitializer
- Auto-detected on Servlet container startup
application-context.xmlpersistence.xmlweb.xml
XML IS OVER.
XML IS OVER,
if you want it*
*which means that you really shouldn't worry, because XML support is definitely not going anywhere. This is a concern that commonly comes up when we talk about annotations and such, but we've said it before and we'll say it again: XML was, is, and ever will be a first class citizen in Spring. The changes in 3.1 just mean that if you don't want XML, you don't have to use it. That's all. kthx, bye.
3.1 RC1 is out
- Now is the time to test
- RC2 in a couple weeks
- GA by year end
Questions?
Thanks!
@cbeams@rstoya05@springframework- this presentation on the web: http://cbeams.github.com/spring-3.1-config