AbstractXmlApplicationContext

Convenient base class for org.springframework.context.ApplicationContext implementations, drawing configuration from XML documents containing bean definitions understood by an org.springframework.beans.factory.xml.XmlBeanDefinitionReader.

Subclasses just have to implement the #getConfigResources and/or the #getConfigLocations method. Furthermore, they might override the #getResourceByPath hook to interpret relative paths in an environment-specific fashion, and/or #getResourcePatternResolver for extended pattern resolution.

ApplicationObjectSupport

Convenient superclass for application objects that want to be aware of the application context, e.g. for custom lookup of collaborating beans or for context-specific resource access. It saves the application context reference and provides an initialization callback method. Furthermore, it offers numerous convenience methods for message lookup.

There is no requirement to subclass this class: It just makes things a little easier if you need access to the context, e.g. for access to file resources or to the message source. Note that many application objects do not need to be aware of the application context at all, as they can receive collaborating beans via bean references.

Many framework classes are derived from this class, particularly within the web support.

BeanDefinitionDsl

Class implementing functional bean definition Kotlin DSL.

ClassPathXmlApplicationContext

Standalone XML application context, taking the context definition files from the class path, interpreting plain paths as class path resource names that include the package path (e.g. "mypackage/myresource.txt"). Useful for test harnesses as well as for application contexts embedded within JARs.

The config location defaults can be overridden via #getConfigLocations, Config locations can either denote concrete files like "/myfiles/context.xml" or Ant-style patterns like "/myfiles/*-context.xml" (see the org.springframework.util.AntPathMatcher javadoc for pattern details).

Note: In case of multiple config locations, later bean definitions will override ones defined in earlier loaded files. This can be leveraged to deliberately override certain bean definitions via an extra XML file.

This is a simple, one-stop shop convenience ApplicationContext. Consider using the GenericApplicationContext class in combination with an org.springframework.beans.factory.xml.XmlBeanDefinitionReader for more flexible context setup.

ConversionServiceFactoryBean

A factory providing convenient access to a ConversionService configured with converters appropriate for most environments. Set the "converters" property to supplement the default converters.

This implementation creates a DefaultConversionService. Subclasses may override #createConversionService() in order to return a GenericConversionService instance of their choosing.

Like all FactoryBean implementations, this class is suitable for use when configuring a Spring application context using Spring <beans> XML. When configuring the container with org.springframework.context.annotation.Configuration classes, simply instantiate, configure and return the appropriate ConversionService object from a method.

DefaultLifecycleProcessor

Default implementation of the LifecycleProcessor strategy.

DefaultMessageSourceResolvable

Default implementation of the MessageSourceResolvable interface. Offers an easy way to store all the necessary values needed to resolve a message via a org.springframework.context.MessageSource.

DelegatingMessageSource

Empty MessageSource that delegates all calls to the parent MessageSource. If no parent is available, it simply won't resolve any message.

Used as placeholder by AbstractApplicationContext, if the context doesn't define its own MessageSource. Not intended for direct use in applications.

EmbeddedValueResolutionSupport

Convenient base class for components with a need for embedded value resolution (i.e. org.springframework.context.EmbeddedValueResolverAware consumers).

FileSystemXmlApplicationContext

Standalone XML application context, taking the context definition files from the file system or from URLs, interpreting plain paths as relative file system locations (e.g. "mydir/myfile.txt"). Useful for test harnesses as well as for standalone environments.

NOTE: Plain paths will always be interpreted as relative to the current VM working directory, even if they start with a slash. (This is consistent with the semantics in a Servlet container.) Use an explicit "file:" prefix to enforce an absolute file path.

The config location defaults can be overridden via #getConfigLocations, Config locations can either denote concrete files like "/myfiles/context.xml" or Ant-style patterns like "/myfiles/*-context.xml" (see the org.springframework.util.AntPathMatcher javadoc for pattern details).

Note: In case of multiple config locations, later bean definitions will override ones defined in earlier loaded files. This can be leveraged to deliberately override certain bean definitions via an extra XML file.

This is a simple, one-stop shop convenience ApplicationContext. Consider using the GenericApplicationContext class in combination with an org.springframework.beans.factory.xml.XmlBeanDefinitionReader for more flexible context setup.

GenericGroovyApplicationContext

An org.springframework.context.ApplicationContext implementation that extends GenericApplicationContext and implements GroovyObject such that beans can be retrieved with the dot de-reference syntax instead of using #getBean.

Consider this as the equivalent of GenericXmlApplicationContext for Groovy bean definitions, or even an upgrade thereof since it seamlessly understands XML bean definition files as well. The main difference is that, within a Groovy script, the context can be used with an inline bean definition closure as follows:

 import org.hibernate.SessionFactory import org.apache.commons.dbcp.BasicDataSource def context = new GenericGroovyApplicationContext() context.reader.beans { dataSource(BasicDataSource) { // <--- invokeMethod driverClassName = "org.hsqldb.jdbcDriver" url = "jdbc:hsqldb:mem:grailsDB" username = "sa" // <-- setProperty password = "" settings = [mynew:"setting"] } sessionFactory(SessionFactory) { dataSource = dataSource // <-- getProperty for retrieving references } myService(MyService) { nestedBean = { AnotherBean bean -> // <-- setProperty with closure for nested bean dataSource = dataSource } } } context.refresh() 

Alternatively, load a Groovy bean definition script like the following from an external resource (e.g. an "applicationContext.groovy" file):

 import org.hibernate.SessionFactory import org.apache.commons.dbcp.BasicDataSource beans { dataSource(BasicDataSource) { driverClassName = "org.hsqldb.jdbcDriver" url = "jdbc:hsqldb:mem:grailsDB" username = "sa" password = "" settings = [mynew:"setting"] } sessionFactory(SessionFactory) { dataSource = dataSource } myService(MyService) { nestedBean = { AnotherBean bean -> dataSource = dataSource } } } 

With the following Java code creating the GenericGroovyApplicationContext (potentially using Ant-style '*'/'**' location patterns):

 GenericGroovyApplicationContext context = new GenericGroovyApplicationContext(); context.load("org/myapp/applicationContext.groovy"); context.refresh(); 

Or even more concise, provided that no extra configuration is needed:

 ApplicationContext context = new GenericGroovyApplicationContext("org/myapp/applicationContext.groovy"); 

This application context also understands XML bean definition files, allowing for seamless mixing and matching with Groovy bean definition files. ".xml" files will be parsed as XML content; all other kinds of resources will be parsed as Groovy scripts.

GenericXmlApplicationContext

Convenient application context with built-in XML support. This is a flexible alternative to ClassPathXmlApplicationContext and FileSystemXmlApplicationContext, to be configured via setters, with an eventual #refresh() call activating the context.

In case of multiple configuration files, bean definitions in later files will override those defined in earlier files. This can be leveraged to intentionally override certain bean definitions via an extra configuration file appended to the list.

LiveBeansView

Adapter for live beans view exposure, building a snapshot of current beans and their dependencies from either a local ApplicationContext (with a local LiveBeansView bean definition) or all registered ApplicationContexts (driven by the {@value #MBEAN_DOMAIN_PROPERTY_NAME} environment property).

Note: This feature is still in beta and primarily designed for use with Spring Tool Suite 3.1 and higher.

LiveBeansViewMBean

MBean operation interface for the LiveBeansView feature.

MessageSourceResourceBundle

Helper class that allows for accessing a Spring org.springframework.context.MessageSource as a java.util.ResourceBundle. Used for example to expose a Spring MessageSource to JSTL web views.

MessageSourceSupport

Base class for message source implementations, providing support infrastructure such as java.text.MessageFormat handling but not implementing concrete methods defined in the org.springframework.context.MessageSource.

AbstractMessageSource derives from this class, providing concrete getMessage implementations that delegate to a central template method for message code resolution.

PropertySourcesPlaceholderConfigurer

Specialization of PlaceholderConfigurerSupport that resolves ${...} placeholders within bean definition property values and @Value annotations against the current Spring Environment and its set of PropertySources.

This class is designed as a general replacement for PropertyPlaceholderConfigurer in Spring 3.1 applications. It is used by default to support the property-placeholder element in working against the spring-context-3.1 XSD, whereas spring-context versions <= 3.0 default to PropertyPlaceholderConfigurer to ensure backward compatibility. See the spring-context XSD documentation for complete details.

Any local properties (e.g. those added via #setProperties, #setLocations et al.) are added as a PropertySource. Search precedence of local properties is based on the value of the localOverride property, which is by default false meaning that local properties are to be searched last, after all environment property sources.

See org.springframework.core.env.ConfigurableEnvironment and related javadocs for details on manipulating environment property sources.

ReloadableResourceBundleMessageSource

Spring-specific org.springframework.context.MessageSource implementation that accesses resource bundles using specified basenames, participating in the Spring org.springframework.context.ApplicationContext's resource loading.

In contrast to the JDK-based ResourceBundleMessageSource, this class uses java.util.Properties instances as its custom data structure for messages, loading them via a org.springframework.util.PropertiesPersister strategy from Spring Resource handles. This strategy is not only capable of reloading files based on timestamp changes, but also of loading properties files with a specific character encoding. It will detect XML property files as well.

Note that the basenames set as "basenames" property are treated in a slightly different fashion than the "basenames" property of ResourceBundleMessageSource. It follows the basic ResourceBundle rule of not specifying file extension or language codes, but can refer to any Spring resource location (instead of being restricted to classpath resources). With a "classpath:" prefix, resources can still be loaded from the classpath, but "cacheSeconds" values other than "-1" (caching forever) might not work reliably in this case.

For a typical web application, message files could be placed in WEB-INF: e.g. a "WEB-INF/messages" basename would find a "WEB-INF/messages.properties", "WEB-INF/messages_en.properties" etc arrangement as well as "WEB-INF/messages.xml", "WEB-INF/messages_en.xml" etc. Note that message definitions in a previous resource bundle will override ones in a later bundle, due to sequential lookup.

This MessageSource can easily be used outside of an org.springframework.context.ApplicationContext: it will use a org.springframework.core.io.DefaultResourceLoader as default, simply getting overridden with the ApplicationContext's resource loader if running in a context. It does not have any other specific dependencies.

Thanks to Thomas Achleitner for providing the initial implementation of this message source!

ResourceBundleMessageSource

org.springframework.context.MessageSource implementation that accesses resource bundles using specified basenames. This class relies on the underlying JDK's java.util.ResourceBundle implementation, in combination with the JDK's standard message parsing provided by java.text.MessageFormat.

This MessageSource caches both the accessed ResourceBundle instances and the generated MessageFormats for each message. It also implements rendering of no-arg messages without MessageFormat, as supported by the AbstractMessageSource base class. The caching provided by this MessageSource is significantly faster than the built-in caching of the java.util.ResourceBundle class.

The basenames follow java.util.ResourceBundle conventions: essentially, a fully-qualified classpath location. If it doesn't contain a package qualifier (such as org.mypackage), it will be resolved from the classpath root. Note that the JDK's standard ResourceBundle treats dots as package separators: This means that "test.theme" is effectively equivalent to "test/theme".

SimpleThreadScope

A simple thread-backed Scope implementation.

NOTE: This thread scope is not registered by default in common contexts. Instead, you need to explicitly assign it to a scope key in your setup, either through org.springframework.beans.factory.config.ConfigurableBeanFactory#registerScope or through a org.springframework.beans.factory.config.CustomScopeConfigurer bean.

SimpleThreadScope does not clean up any objects associated with it. As such, it is typically preferable to use org.springframework.web.context.request.RequestScope in web environments.

For an implementation of a thread-based Scope with support for destruction callbacks, refer to the Spring by Example Custom Thread Scope Module.

Thanks to Eugene Kuleshov for submitting the original prototype for a thread scope!

StaticApplicationContext

org.springframework.context.ApplicationContext implementation which supports programmatic registration of beans and messages, rather than reading bean definitions from external configuration sources. Mainly useful for testing.

StaticMessageSource

Simple implementation of org.springframework.context.MessageSource which allows messages to be registered programmatically. This MessageSource supports basic internationalization.

Intended for testing rather than for use in production systems.

GenericApplicationContext

Extension for GenericApplicationContext allowing GenericApplicationContext { ... } style initialization.

beans

Functional bean definition Kotlin DSL.

registerBean

Extension for GenericApplicationContext.registerBean providing a registerBean<Foo>() variant.

Extension for GenericApplicationContext.registerBean providing a registerBean<Foo>("foo") variant.

Extension for GenericApplicationContext.registerBean providing a registerBean { Foo() } variant.

Extension for GenericApplicationContext.registerBean providing a registerBean("foo") { Foo() } variant.