What is ApplicationContext?
● Extension of BeanFactory interface
– It provides all the same functionality and more
● Supports an infrastructure to enable lots of enterprise-specific features such as transactions and AOP
● Used in a more framework-oriented style by using layering and hierarchical contexts
providing extra features over BeanFactory
Features of ApplicationContext
● Extra features over BeanFactory
– Additional life-cycle interfaces
– Event propagation to beans implementing the ApplicationListener interface
– MessageSource, providing access to messages in, i18n-style
– Access to resources, such as URLs and files
– Loading of multiple (hierarchical) contexts, allowing each to be focused on one particular layer, for example the web layer of an application
When to Use ApplicationContext?
● Use ApplicationContext over BeanFactory to take advantage of its extended functionality
– Except for a few limited situations such as perhaps in an Applet, where memory consumption might be critical, and a few extra kilobytes might make a difference
How to use ApplicationContext?
● Many users will use ApplicationContext in a completely declarative fashion, not even having to create it manually, but instead relying on support classes such as ContextLoader to automatically start an ApplicationContext as part of the normal startup process of a J2EE webapp
– It is still possible to programmatically create an ApplicationContext
ApplicationContext: Life-cycle
Life-cycle Interfaces
● ApplicationContextAware interface
– A bean which implements this interface will be called on creation of the bean, using the interface's setApplicationContext() method, and provided with a reference to the context, which may be stored for later interaction with the context
Example: ApplicationContextAware
public class Publisher implements ApplicationContextAware {
private ApplicationContext ctx;
// This method will be called by the container
public void setApplicationContext( ApplicationContext applicationContext)
throws BeansException {
// Save the ApplicationContext object for
// later use.
this.ctx = applicationContext;
}
// Code that uses ApplicationContext
Life-cycle Interfaces
● BeanPostProcessor interface
– In an ApplicationContext, any deployed bean which implements this interface is automatically detected and registered as a bean post-processor, to be called appropriately at creation time for each bean in the factory
ApplicationContext: Propagating Events
● Event handling in the ApplicationContext is provided through the ApplicationEvent class and ApplicationListener interface
– If a bean which implements the ApplicationListener interface is deployed into the context, every time an ApplicationEvent gets published to the
ApplicationContext, that bean will be notified
– Essentially, this is the standard Observer design pattern.
Three Built-in Events
● ContextRefreshEvent
– ApplicationContext is initialized or refreshed
● ContextClosedEvent
– ApplicationContext is closed
● RequestHandleEvent
– A web-specific event telling all beans that a HTTP request has been serviced
Example: Event Handling
● Configuration in the ApplicationContext.xml - whenever you receive an email from an address from a black list, send a notification to spam@list.org
<bean id="emailer" class="example.EmailBean">
<property name="blackList">
<list>
<value>black@list.org</value>
<value>white@list.org</value>
<value>john@doe.org</value>
</list>
</property>
</bean>
<bean id="blackListListener" class="example.BlackListNotifier">
<property name="notificationAddress" value="spam@list.org"/>
</bean>
● Bean class – publish events through ApplicationContext object
public class EmailBean implements ApplicationContextAware {
/** the blacklist */
private List blackList;
public void setBlackList(List blackList) {
this.blackList = blackList;
}
public void setApplicationContext(ApplicationContext ctx) {
this.ctx = ctx;
}
public void sendEmail(String address, String text) {
if (blackList.contains(address)) {
BlackListEvent evt = new BlackListEvent(address, text);
ctx.publishEvent(evt);
return;
}
// send email
}
● Notifier class – gets event notifications
public class BlackListNotifier implement ApplicationListener {
/** notification address */
private String notificationAddress;
public void setNotificationAddress(String notificationAddress) {
this.notificationAddress = notificationAddress;
}
public void onApplicationEvent(ApplicationEvent evt) {
if (evt instanceof BlackListEvent) {
// notify appropriate person
}
}
}
ApplicationContext: Internationalization
Using MessageSource
● ResourceBundleMessageSource is an implementation of MessageSource interface
● The example below assumes you have three resource bundles defined on your classpath called format, exceptions and windows
<beans>
<bean id="messageSource”
class="org.springframework.context.support.ResourceBundleMessageSource">
<property name="basenames">
<list>
<value>format</value>
<value>exceptions</value>
<value>windows</value>
</list>
</property>
</bean>
</beans>
ApplicationContext: Resources
Getting Resources
● Resource x = contextObject.getResource(String location);
● Returns a Resource handle for the specified resource
– getClass()
– getURL()
● Supported formats
– fully qualified URLs, e.g. "file:C:/test.dat".
– classpath pseudo-URLs, e.g. "classpath:test.dat".
– relative file paths, e.g. "WEB-INF/test.dat".
Example: Getting a Resource
ApplicationContext ctx = new FileSystemXmlApplicationContext( "./events/events.xml");
Resource res1 = ctx.getResource("test.txt");
Resource res2 = ctx.getResource("classpath:log4j.properties");
Resource res3 = ctx.getResource("http://www.google.co.uk");
ApplicationContext: In the Web Application
ApplicationContext Instance
● As opposed to the BeanFactory, which will often be created programmatically,
ApplicationContext instances can be created declaratively using for example a ContextLoader
● The listener inspects the contextConfigLocation parameter. If it doesn't exist, it'll use /WEB-INF/applicationContext.xml as a default
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/daoContext.xml /WEBINF/
applicationContext.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
PropertyPlaceholder Configurer
● Used to externalize property values from a BeanFactory definition, into another separate file in the standard Java Properties format
– Useful to allow the person deploying an application to customize enviroment-specific properties (for example database URLs, usernames and passwords), without the complexity or risk of modifying the main XML definition file or files for the container
PropertyPlaceholderConfigurer
<!-- Configurer that replaces ${...} placeholders with values from a
properties file -->
<!-- (in this case, JDBC-related settings for the dataSource
definition below) -->
<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location" value="/WEB-INF/jdbc.properties"/>
</bean>
jdbc.properties
# Properties file with JDBC-related settings.
# Applied by PropertyPlaceholderConfigurer from "applicationContext-*.xml".
# Targeted at system administrators, to avoid touching the context XML files.
jdbc.driverClassName=org.hsqldb.jdbcDriver
#jdbc.driverClassName=com.mysql.jdbc.Driver
jdbc.url=jdbc:hsqldb:hsql://localhost:9001
#jdbc.url=jdbc:mysql://localhost:3306/petclinic
jdbc.username=sa
jdbc.password=
# Property that determines the Hibernate dialect
# (only applied with "applicationContext-hibernate.xml")
hibernate.dialect=org.hibernate.dialect.HSQLDialect
#hibernate.dialect=org.hibernate.dialect.MySQLDialect
# Property that determines the JDBC implementation of Clinic
# (only applied with "applicationContext-jdbc.xml")
petclinic.jdbcImplBeanName=hsqlClinic
#petclinic.jdbcImplBeanName=mysqlClinic
Checking for Dependencies
● Used to check for the existence of unresolved dependencies of a bean deployed into the container
– These are JavaBeans properties of the bean, which do not have actual values set for them in the bean definition, or alternately provided automatically by the autowiring feature
● This feature is sometimes useful when you want to ensure that all properties (or all properties of a certain type) are set on a bean.
● Can also be enabled and disabled per bean
Dependency Checking Modes
● none – no dependency checking
● simple – dependency checking is performed for primitive types and collections (everything except collaborators)
● object – dependency checking is performed for collaborators only
● all – dependency checking is done for collaborators, primitive types and collections
Singleton
● When a bean is a singleton, only one shared instance of the bean will be managed, and all requests for beans with an id or ids matching that bean definition will result in that one specific bean instance being returned by the Spring container
● Default behavior in Spring
Example: Singleton (version 1.2.x)
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
<!-- Singleton examples -->
<bean id="Singleton" class="java.lang.String" singleton="true">
<constructor-arg>
<value>Value</value>
</constructor-arg>
</bean>
</beans>
PropertyEditor
● A PropertyEditor is a class that converts a property's value to and from its native type
representation into a String
● Spring comes with built-in PropertyEditor implementations that are preregistered with the BeanFactory
– ClassEditor
– FileEditor
– LocaleEditor
– PropertiesEditor
– URLEditor
Factory
FactoryBean
● Interface to be implemented by objects used within a BeanFactory that are themselves
factories.
● If a bean implements this interface, it is used as a factory, not directly as a bean
● getObject() method
– Return an instance (possibly shared or independent) of the object managed by this factory
● Extension of BeanFactory interface
– It provides all the same functionality and more
● Supports an infrastructure to enable lots of enterprise-specific features such as transactions and AOP
● Used in a more framework-oriented style by using layering and hierarchical contexts
providing extra features over BeanFactory
Features of ApplicationContext
● Extra features over BeanFactory
– Additional life-cycle interfaces
– Event propagation to beans implementing the ApplicationListener interface
– MessageSource, providing access to messages in, i18n-style
– Access to resources, such as URLs and files
– Loading of multiple (hierarchical) contexts, allowing each to be focused on one particular layer, for example the web layer of an application
When to Use ApplicationContext?
● Use ApplicationContext over BeanFactory to take advantage of its extended functionality
– Except for a few limited situations such as perhaps in an Applet, where memory consumption might be critical, and a few extra kilobytes might make a difference
How to use ApplicationContext?
● Many users will use ApplicationContext in a completely declarative fashion, not even having to create it manually, but instead relying on support classes such as ContextLoader to automatically start an ApplicationContext as part of the normal startup process of a J2EE webapp
– It is still possible to programmatically create an ApplicationContext
ApplicationContext: Life-cycle
Life-cycle Interfaces
● ApplicationContextAware interface
– A bean which implements this interface will be called on creation of the bean, using the interface's setApplicationContext() method, and provided with a reference to the context, which may be stored for later interaction with the context
Example: ApplicationContextAware
public class Publisher implements ApplicationContextAware {
private ApplicationContext ctx;
// This method will be called by the container
public void setApplicationContext( ApplicationContext applicationContext)
throws BeansException {
// Save the ApplicationContext object for
// later use.
this.ctx = applicationContext;
}
// Code that uses ApplicationContext
Life-cycle Interfaces
● BeanPostProcessor interface
– In an ApplicationContext, any deployed bean which implements this interface is automatically detected and registered as a bean post-processor, to be called appropriately at creation time for each bean in the factory
ApplicationContext: Propagating Events
● Event handling in the ApplicationContext is provided through the ApplicationEvent class and ApplicationListener interface
– If a bean which implements the ApplicationListener interface is deployed into the context, every time an ApplicationEvent gets published to the
ApplicationContext, that bean will be notified
– Essentially, this is the standard Observer design pattern.
Three Built-in Events
● ContextRefreshEvent
– ApplicationContext is initialized or refreshed
● ContextClosedEvent
– ApplicationContext is closed
● RequestHandleEvent
– A web-specific event telling all beans that a HTTP request has been serviced
Example: Event Handling
● Configuration in the ApplicationContext.xml - whenever you receive an email from an address from a black list, send a notification to spam@list.org
<bean id="emailer" class="example.EmailBean">
<property name="blackList">
<list>
<value>black@list.org</value>
<value>white@list.org</value>
<value>john@doe.org</value>
</list>
</property>
</bean>
<bean id="blackListListener" class="example.BlackListNotifier">
<property name="notificationAddress" value="spam@list.org"/>
</bean>
● Bean class – publish events through ApplicationContext object
public class EmailBean implements ApplicationContextAware {
/** the blacklist */
private List blackList;
public void setBlackList(List blackList) {
this.blackList = blackList;
}
public void setApplicationContext(ApplicationContext ctx) {
this.ctx = ctx;
}
public void sendEmail(String address, String text) {
if (blackList.contains(address)) {
BlackListEvent evt = new BlackListEvent(address, text);
ctx.publishEvent(evt);
return;
}
// send email
}
● Notifier class – gets event notifications
public class BlackListNotifier implement ApplicationListener {
/** notification address */
private String notificationAddress;
public void setNotificationAddress(String notificationAddress) {
this.notificationAddress = notificationAddress;
}
public void onApplicationEvent(ApplicationEvent evt) {
if (evt instanceof BlackListEvent) {
// notify appropriate person
}
}
}
ApplicationContext: Internationalization
Using MessageSource
● ResourceBundleMessageSource is an implementation of MessageSource interface
● The example below assumes you have three resource bundles defined on your classpath called format, exceptions and windows
<beans>
<bean id="messageSource”
class="org.springframework.context.support.ResourceBundleMessageSource">
<property name="basenames">
<list>
<value>format</value>
<value>exceptions</value>
<value>windows</value>
</list>
</property>
</bean>
</beans>
ApplicationContext: Resources
Getting Resources
● Resource x = contextObject.getResource(String location);
● Returns a Resource handle for the specified resource
– getClass()
– getURL()
● Supported formats
– fully qualified URLs, e.g. "file:C:/test.dat".
– classpath pseudo-URLs, e.g. "classpath:test.dat".
– relative file paths, e.g. "WEB-INF/test.dat".
Example: Getting a Resource
ApplicationContext ctx = new FileSystemXmlApplicationContext( "./events/events.xml");
Resource res1 = ctx.getResource("test.txt");
Resource res2 = ctx.getResource("classpath:log4j.properties");
Resource res3 = ctx.getResource("http://www.google.co.uk");
ApplicationContext: In the Web Application
ApplicationContext Instance
● As opposed to the BeanFactory, which will often be created programmatically,
ApplicationContext instances can be created declaratively using for example a ContextLoader
● The listener inspects the contextConfigLocation parameter. If it doesn't exist, it'll use /WEB-INF/applicationContext.xml as a default
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/daoContext.xml /WEBINF/
applicationContext.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
PropertyPlaceholder Configurer
● Used to externalize property values from a BeanFactory definition, into another separate file in the standard Java Properties format
– Useful to allow the person deploying an application to customize enviroment-specific properties (for example database URLs, usernames and passwords), without the complexity or risk of modifying the main XML definition file or files for the container
PropertyPlaceholderConfigurer
<!-- Configurer that replaces ${...} placeholders with values from a
properties file -->
<!-- (in this case, JDBC-related settings for the dataSource
definition below) -->
<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location" value="/WEB-INF/jdbc.properties"/>
</bean>
jdbc.properties
# Properties file with JDBC-related settings.
# Applied by PropertyPlaceholderConfigurer from "applicationContext-*.xml".
# Targeted at system administrators, to avoid touching the context XML files.
jdbc.driverClassName=org.hsqldb.jdbcDriver
#jdbc.driverClassName=com.mysql.jdbc.Driver
jdbc.url=jdbc:hsqldb:hsql://localhost:9001
#jdbc.url=jdbc:mysql://localhost:3306/petclinic
jdbc.username=sa
jdbc.password=
# Property that determines the Hibernate dialect
# (only applied with "applicationContext-hibernate.xml")
hibernate.dialect=org.hibernate.dialect.HSQLDialect
#hibernate.dialect=org.hibernate.dialect.MySQLDialect
# Property that determines the JDBC implementation of Clinic
# (only applied with "applicationContext-jdbc.xml")
petclinic.jdbcImplBeanName=hsqlClinic
#petclinic.jdbcImplBeanName=mysqlClinic
Checking for Dependencies
● Used to check for the existence of unresolved dependencies of a bean deployed into the container
– These are JavaBeans properties of the bean, which do not have actual values set for them in the bean definition, or alternately provided automatically by the autowiring feature
● This feature is sometimes useful when you want to ensure that all properties (or all properties of a certain type) are set on a bean.
● Can also be enabled and disabled per bean
Dependency Checking Modes
● none – no dependency checking
● simple – dependency checking is performed for primitive types and collections (everything except collaborators)
● object – dependency checking is performed for collaborators only
● all – dependency checking is done for collaborators, primitive types and collections
Singleton
● When a bean is a singleton, only one shared instance of the bean will be managed, and all requests for beans with an id or ids matching that bean definition will result in that one specific bean instance being returned by the Spring container
● Default behavior in Spring
Example: Singleton (version 1.2.x)
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
<!-- Singleton examples -->
<bean id="Singleton" class="java.lang.String" singleton="true">
<constructor-arg>
<value>Value</value>
</constructor-arg>
</bean>
</beans>
PropertyEditor
● A PropertyEditor is a class that converts a property's value to and from its native type
representation into a String
● Spring comes with built-in PropertyEditor implementations that are preregistered with the BeanFactory
– ClassEditor
– FileEditor
– LocaleEditor
– PropertiesEditor
– URLEditor
Factory
FactoryBean
● Interface to be implemented by objects used within a BeanFactory that are themselves
factories.
● If a bean implements this interface, it is used as a factory, not directly as a bean
● getObject() method
– Return an instance (possibly shared or independent) of the object managed by this factory
