modern enterprise app config
you
modern enterprise app config
enterprise
- think big
- (big enough to hire own devs)
- typically not tech companies
- finance, media, insurance, gov't, ...
enterprise application
- typically long-lived
- teams change over time
- tech and requirements do too
enterprise application
- often large
- ... in size of codebase
- ... in no. of devs
enterprise application
- legacy and diversity are the rule
enterprise app configuration
- what components are involved?
- how are they parameterized?
- what dependencies exist?
- how are they satisfied?
modern enterprise app config
- concise
- comprehensive
- clear and communicative
- flexible and extensible
- code-based and typesafe
the Spring mission
- to provide comprehensive infrastructural support for building enterprise applications
ok... but what exactly is Spring?
Spring Framework 1.x
(2004)
2004
spring ~= spring-framework
Spring Framework 3.x
(2012)
2012
spring != spring-framework
2012
spring >> spring-framework
spring ==
spring-frameworkspring-securityspring-integrationspring-batchspring-data-*spring-social
spring ==
spring-roospring-amqpspring-webflowspring-wsspring-net...
spring == spring-*
spring ==
comprehensive infrastructural support
- ...and there's a lot of infrastructure out there!
- configuration is just one (important) concern
which brings us back to...
modern enterprise app config
the approach
·
·
the approach
POJOs + 3rd party
components
·
the approach
POJOs + 3rd party
components
configuration
instructions
·
the approach
POJOs + 3rd party
components
↓
configuration ┌─────────────────────┐
instructions → │ the Spring container│
└─────────────────────┘
·
the approach
POJOs + 3rd party
components
↓
configuration ┌─────────────────────┐
instructions → │ (ApplicationContext)│
└─────────────────────┘
·
the approach
POJOs + 3rd party
components
↓
configuration ┌─────────────────────┐
instructions → │ the Spring container│
└─────────────────────┘
·
the approach
POJOs + 3rd party
components
↓
configuration ┌─────────────────────┐
instructions → │ the Spring container│
└─────────────────────┘
⇊
┌─────────────────────────┐
│ fully configured system │
│ ready for use │
└─────────────────────────┘
you get
- one consistent mechanism for config
- fail-fast behavior at startup
- dependency injection vs dependency lookup
- ... leading to simple, testable POJO components
- ability to enhance behavior through AOP
config style
POJOs + 3rd party
components
↓
configuration ┌─────────────────────┐
instructions → │ the Spring container│
└─────────────────────┘
⇊
┌─────────────────────────┐
│ fully configured system │
│ ready for use │
└─────────────────────────┘
config style
POJOs + 3rd party
components
↓
<beans> ┌─────────────────────┐
XML → │ the Spring container│
└─────────────────────┘
⇊
┌─────────────────────────┐
│ fully configured system │
│ ready for use │
└─────────────────────────┘
<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 .../>
</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 .../>
</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 .../>
<import resource="more-beans.xml"/>
</beans><beans> xml
- simple
- general purpose
- flexible
but...
<beans> xml
- verbose
- not typesafe
- wants special tooling
<namespace:*> xml helps
e.g.
<tx:annotation-driven/>
<aop:aspectj-autoproxy/>
<jee:jndi-lookup/>
<util:list/><namespace:*> xml
- concise
- powerful
- easier to use
but...
<namespace:*> xml
- opaque
- non-extensible
- difficult to write your own
config style
POJOs + 3rd party
components
↓
<beans> ┌─────────────────────┐
XML → │ the Spring container│
└─────────────────────┘
⇊
┌─────────────────────────┐
│ fully configured system │
│ ready for use │
└─────────────────────────┘
config style
POJOs + 3rd party
components
↓
<beans> + ┌─────────────────────┐
<namespace:*> → │ the Spring container│
XML └─────────────────────┘
⇊
┌─────────────────────────┐
│ fully configured system │
│ ready for use │
└─────────────────────────┘
config style
POJOs + 3rd party
components
↓
@Component- ┌─────────────────────┐
scanning → │ the Spring container│
+ @Autowired └─────────────────────┘
⇊
┌─────────────────────────┐
│ fully configured system │
│ ready for use │
└─────────────────────────┘
@Component
public class Foo {
// ...
}
@Component
public class Bar {
private Foo foo;
@Autowired
public void setFoo(Foo foo) {
this.foo = foo;
}
}@Component-scanning + @Autowired
- eliminates a lot of xml
- really concise, convenient
- now widely used
- especially for MVC
@Controllers
but...
@Component-scanning + @Autowired
- 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.foo;
@Component
public class Bar {
@Autowired
public void setFoo(Foo foo) { ... }
}I mean, if you've got this
package com.foo;
@Component
public class Bar {
@Autowired
public void setFoo(Foo foo) { ... }
}... then this is kind of ironic, right?
<context:component-scan base-package="com.foo"/>config style
POJOs + 3rd party
components
↓
@Component- ┌─────────────────────┐
scanning → │ the Spring container│
+ @Autowired └─────────────────────┘
⇊
┌─────────────────────────┐
│ fully configured system │
│ ready for use │
└─────────────────────────┘
config style
POJOs + 3rd party
components
↓
@Configuration ┌─────────────────────┐
+ @Bean → │ the Spring container│
└─────────────────────┘
⇊
┌─────────────────────────┐
│ fully configured system │
│ ready for use │
└─────────────────────────┘
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) {
}
}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 typesafe 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"));
}
}@Configuration
- typesafe, object-oriented
- can configure any component
- complete programmatic control
- no special tooling required
- centralized, blueprint-style
but...
@Configuration
- no equivalent to
<namespace:*/> - xml still required for tx mgmt, aop, etc
@Enable*
@Enable*
(and friends)
e.g.
@EnableTransactionManagement
@EnableAspectJAutoProxy
@EnableLoadTimeWeaving
@EnableScheduling
@EnableAsync
@EnableWebMvc
@ComponentScansimple.
if you've got this
package com.foo;
@Component
public class Bar {
@Autowired
public void setFoo(Foo foo) { ... }
}if you've got this
package com.foo;
@Component
public class Bar {
@Autowired
public void setFoo(Foo foo) { ... }
}... then this is kind of ironic ...
<context:component-scan base-package="com.foo"/>I mean, if you've got this
package com.foo;
@Component
public class Bar {
@Autowired
public void setFoo(Foo foo) { ... }
}... but this makes a lot more sense.
@ComponentScan("com.foo")and if you've got this
package com.foo;
@Repository
public class WidgetRepo {
@Transactional
public void add(Widget widget) { ... }
}and if you've got this
package com.foo;
@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.foo;
@Repository
public class WidgetRepo {
@Transactional
public void add(Widget widget) { ... }
}... when you could do this?
@EnableTransactionManagementexample
example
@EnableSchedulingsome component
package com.foo;
public class ChatterBox {
public void saySomething() {
System.out.println(randomWord());
}
}some component
package com.foo;
public class ChatterBox {
@Scheduled(fixedRate=1000)
public void saySomething() {
System.out.println(randomWord());
}
}some component
package com.foo;
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.foo;
public class ChatterBox {
// "hey Spring, call this
@Scheduled(fixedRate=1000) // method every second"
public void saySomething() {
System.out.println(randomWord());
}
}configuration
package com.foo.config;
@Configuration
public class Config {
@Bean
public ChatterBox chatterBox() {
return new ChatterBox();
}
}configuration
package com.foo.config;
@Configuration
@EnableScheduling
public class Config {
@Bean
public ChatterBox chatterBox() {
return new ChatterBox();
}
}configuration
package com.foo.config;
@Configuration
@EnableScheduling // look for and process @Scheduled
public class Config {
@Bean
public ChatterBox chatterBox() {
return new ChatterBox();
}
}configuration
package com.foo.config;
@Configuration
@EnableScheduling
public class Config {
@Bean
public ChatterBox chatterBox() { // Spring ensures
return new ChatterBox(); // saySomething() method is
} // called once per second
}@Enable* benefits
- easy to see what's going on
- easy to write your own
- adapts smoothly from simple to sophisticated
- supported beyond core spring-framework
- e.g. spring-data's
@EnableMongoRepositories
code-based configuration
- is complete as of Spring Framework 3.1
- can configure all major container features
- mix and match styles as desired
but...
but... ?
no buts.
no buts.
- code-based configuration:
- 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 builds against Hibernate 4
- new orm.hibernate4 packaging
familiar?
<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>we can do better than that.
@Bean
public SessionFactory sessionFactory() {
return new LocalSessionFactoryBuilder(dataSource())
.addAnnotatedClasses(Person.class, Account.class)
.buildSessionFactory();
}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.foo.domain");
return emf;
}@Bean
public LocalContainerEntityManagerFactoryBean emf() {
LocalContainerEntityManagerFactoryBean emf =
new LocalContainerEntityManagerFactoryBean();
emf.setDataSource(dataSource());
// scan classpath for JPA @Entity types
emf.setPackagesToScan("com.foo.domain");
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)
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
- allows code-based config of servlet container
- 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. These new features just mean that if you don't want XML, you don't have to use it. That's all. kthx, bye.
config style
POJOs + 3rd party
components
↓
@Configuration ┌─────────────────────┐
+ @Bean → │ the Spring container│
└─────────────────────┘
⇊
┌─────────────────────────┐
│ fully configured system │
│ ready for use │
└─────────────────────────┘
config style
POJOs + 3rd party
components
↓
@Configuration ┌─────────────────────┐
+ @Bean → │ the Spring container│
+ @Enable* └─────────────────────┘
⇊
┌─────────────────────────┐
│ fully configured system │
│ ready for use │
└─────────────────────────┘
config style
POJOs + 3rd party
components
(hybrid) ↓
<bean> + ┌─────────────────────┐
@Component + → │ the Spring container│
@Configuration └─────────────────────┘
⇊
┌─────────────────────────┐
│ fully configured system │
│ ready for use │
└─────────────────────────┘
recommendations
recommendations
- go for 100% code-based config
@Component+@Autowiredfor "your" components@Beanfor third-party components@Enableto control framework features
modern enterprise app config
- concise
- comprehensive
- clear and communicative
- flexible and extensible
- code-based and typesafe
much more
- Environment and PropertySource APIs
- bean definition profiles
- testing support for
@Configurationclasses - brand-new
spring-scalaproject spring-integrationScala & Groovy DSLs
check it out
- everything in this talk available in 3.1
spring-framework3.2 RC1 is now out- a great time for feedback
- RC2 in a few weeks
- GA by year end
get involved
- everything's on GitHub
- see CONTRIBUTING.md
- new Gradle build in 3.2 makes it easy