| Home >> All >> org >> springframework >> context >> [ support Javadoc ] |
• org.springframework.context.support: Javadoc index of package org.springframework.context.support.
Package Samples:
• org.springframework.context.support: This package builds on the beans package to add support for message sources and for the Observer design pattern, and the ability for application objects to obtain resources using a consistent API.
Classes:
• ReloadableResourceBundleMessageSource: MessageSource that accesses the ResourceBundles with the specified basenames. This class uses java.util.Properties instances as its internal data structure for messages, loading them via a PropertiesPersister strategy: The default strategy can load properties files with a specific encoding. In contrast to ResourceBundleMessageSource, this class supports reloading of properties files through the "cacheSeconds" setting, and also through programmatically clearing the properties cache. Since application servers do typically cache all files loaded from the classpath, it is necessary to store resources ...
• GenericApplicationContext: Generic ApplicationContext implementation that holds a single internal DefaultListableBeanFactory instance and does not assume a specific bean definition format. Implements the BeanDefinitionRegistry interface to allow for applying any bean definition readers to it. Typical usage is to register a variety of bean definitions via the BeanDefinitionRegistry interface and then call refresh to initialize those beans with application context semantics (handling ApplicationContextAware, auto-detecting BeanFactoryPostProcessors, etc). In contrast to other ApplicationContext implementations that create ...
• AbstractRefreshableApplicationContext: Base class for ApplicationContext implementations that are supposed to support multiple refreshs, creating a new internal bean factory instance every time. Typically (but not necessarily), such a context will be driven by a set of config locations to load bean definitions from. The only method to be implemented by subclasses is loadBeanDefinitions , which gets invoked on each refresh. A concrete implementation is supposed to load bean definitions into the given DefaultListableBeanFactory, typically delegating to one or more specific bean definition readers. Note that there is a similar base class ...
• AbstractApplicationContext: Abstract implementation of the ApplicationContext interface. Doesn't mandate the type of storage used for configuration, but implements common context functionality. Uses the Template Method design pattern, requiring concrete subclasses to implement abstract methods. In contrast to a plain bean factory, an ApplicationContext is supposed to detect special beans defined in its bean factory: Therefore, this class automatically registers BeanFactoryPostProcessors, BeanPostProcessors and ApplicationListeners that are defined as beans in the context. A MessageSource may also be supplied as a bean in ...
• ClassPathXmlApplicationContext: Standalone XML application context, taking the context definition files from the class path. Mainly useful for test harnesses, but also for application contexts embedded within JARs. Treats resource paths as class path resources, when using getResource . Only supports full class path resource names that include the package path, like "mypackage/myresource.dat". The config location defaults can be overridden via setConfigLocations , Config locations can either denote concrete files like "/myfiles/context.xml" or Ant-style patterns like "/myfiles/*-context.xml" (see PathMatcher javadoc for pattern ...
• FileSystemXmlApplicationContext: Standalone XML application context, taking the context definition files from the file system or from URLs. Mainly useful for test harnesses, but also for standalone environments. Treats resource paths as file system resources, when using getResource . Resource paths are considered relative to the current VM working directory, even if they start with a slash. The config location defaults can be overridden via setConfigLocations , Config locations can either denote concrete files like "/myfiles/context.xml" or Ant-style patterns like "/myfiles/*-context.xml" (see PathMatcher javadoc for pattern details). ...
• 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 ...
• ResourceEntityResolver: EntityResolver implementation that tries to resolve entity references relative to the resource base of the application context, if applicable. Extends BeansDtdResolver to also provide DTD lookup in the class path. Allows to use standard XML entities to include XML snippets into an application context definition, for example to split a large XML file into various modules. The include paths can be relative to the application context's resource base as usual, instead of relative to the JVM working directory (the XML parser's default). Note: In addition to relative paths, every URL that specifies a ...
• AbstractMessageSource: Abstract implementation of HierarchicalMessageSource interface, making it easy to implement a custom MessageSource. Subclasses must implement the abstract resolveCode method. Supports not only MessageSourceResolvables as primary messages but also resolution of message arguments that are in turn MessageSourceResolvables themselves. This class does not implement caching, thus subclasses can dynamically change messages over time. Subclasses are encouraged to cache their messages in a modification-aware fashion.
• AbstractXmlApplicationContext: Convenient abstract superclass for ApplicationContext implementations, drawing configuration from XML documents containing bean definitions understood by an XmlBeanDefinitionReader. Subclasses just have to implement 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.
• ResourceBundleMessageSource: MessageSource that accesses the ResourceBundles with the specified basenames. This class relies on the underlying JDK's java.util.ResourceBundle implementation. Unfortunately, java.util.ResourceBundle caches loaded bundles indefinitely. Reloading a bundle during VM execution is not possible by any means. As this MessageSource relies on ResourceBundle, it faces the same limitation. Consider ReloadableResourceBundleMessageSource for an alternative.
• ResourceMapFactoryBean: FactoryBean that creates a Map with String keys and Resource values from properties, interpreting passed-in String values as resource locations. Extends PropertiesFactoryBean to inherit the capability of defining local properties and loading from properties files. Implements the ResourceLoaderAware interface to automatically use the context ResourceLoader if running in an ApplicationContext. Uses DefaultResourceLoader else.
• ApplicationContextAwareProcessor: BeanPostProcessor implementation that passes the application context to beans that implement the ApplicationContextAware or ResourceLoaderAware interfaces. If both are implemented, the latter is satisfied first. Application contexts will automatically register this with their underlying bean factory. Applications do not use this directly.
• 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.
• MessageSourceAccessor: Helper class for easy access to messages from a MessageSource, providing various overloaded getMessage methods. Available from ApplicationObjectSupport, but also reusable as a standalone helper to delegate to in application objects.
• StaticMessageSource: Simple implementation of MessageSource that allows messages to be held in a Java object, and added programmatically. This MessageSource supports internationalization. Intended for testing rather than use in production systems.
• DefaultMessageSourceResolvable: Default implementation of the MessageSourceResolvable interface. Offers an easy way to store all the necessary values needed to resolve a message via a MessageSource.
• StaticApplicationContext: ApplicationContext that allows concrete registration of beans and messages in code, rather than from external configuration sources. Mainly useful for testing.
• MessageSourceResourceBundle: Helper class that allows for accessing a MessageSource as a ResourceBundle. Used for example to expose a Spring MessageSource to JSTL web views.
| Home | Contact Us | Privacy Policy | Terms of Service |