| Home >> All >> org >> springframework >> [ context Javadoc ] |
| • | org.springframework.context.access.* (4) | • | org.springframework.context.event.* (6) |
| • | org.springframework.context.i18n.* (3) | • | org.springframework.context.support.* (19) |
• org.springframework.context: Javadoc index of package org.springframework.context.
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.
• org.springframework.context.access
• org.springframework.context.event
• org.springframework.context.i18n
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 ...
• ResourceLoaderAware: Interface to be implemented by any object that wishes to be notified of the ResourceLoader (typically the ApplicationContext) that it runs in. This is an alternative to a full ApplicationContext dependency via the ApplicationContextAware interface. Note that Resource dependencies can also be exposed as bean properties of type Resource, populated via Strings with automatic type conversion by the bean factory. This removes the need for implementing any callback interface just for the purpose of accessing a specific file resource. You typically need a ResourceLoader when your application object has ...
• ApplicationContext: Central interface to provide configuration for an application. This is read-only while the application is running, but may be reloaded if the implementation supports this. An ApplicationContext provides: Bean factory methods, inherited from ListableBeanFactory. This avoids the need for applications to use singletons. The ability to resolve messages, supporting internationalization. Inherited from the MessageSource interface. The ability to load file resources in a generic fashion. Inherited from the ResourceLoader interface. The ability to publish events. Implementations must provide a means of ...
• 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 ...
• ApplicationContextAware: Interface to be implemented by any object that wishes to be notified of the ApplicationContext that it runs in. Implementing this interface makes sense for example when an object requires access to a set of collaborating beans. Note that configuration via bean references is preferable to implementing this interface just for bean lookup purposes. This interface can also be implemented if an object needs access to file resources, i.e. wants to call getResource, or access to the MessageSource. However, it is preferable to implement the more specific ResourceLoaderAware interface or receive a reference ...
• 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). ...
• SimpleApplicationEventMulticaster: Simple implementation of the ApplicationEventMulticaster interface. Multicasts all events to all registered listeners. Doesn't permit multiple instances of the same listener, as it keeps listeners in a HashSet. Note that this class doesn't try to do anything clever to ensure thread safety if listeners are added or removed at runtime. A technique such as Copy-on-Write (Lea:137) could be used to ensure this, but the assumption in this version of this framework is that listeners will be added at application configuration time and not added or removed as the application runs. All listeners are invoked ...
• ContextSingletonBeanFactoryLocator: Variant of SingletonBeanFactoryLocator which creates its internal bean factory reference definition as an ApplicationContext instead of SingletonBeanFactoryLocator's BeanFactory. For almost all usage scenarios, this will not make a difference, since withing that ApplicationContext or BeanFactory you are still free to create either BeanFactories or ApplicationContexts. The main reason one would need to use this class is if BeanPostProcessing (or other ApplicationContext specific features are needed in the bean reference definition itself. Note: This class uses classpath*:beanRefContext.xml as the ...
• 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.
• MessageSource: Interface to be implemented by objects that can resolve messages. This enables parameterization and internationalization of messages. Spring provides two out-of-the-box implementations for production: ResourceBundleMessageSource , built on standard java.util.ResourceBundle ReloadableResourceBundleMessageSource , being able to reload message definitions without restarting the VM
• LocaleContextHolder: Simple holder class that associates a LocaleContext instance with the current thread. Used as a central holder for the current Locale in Spring, wherever necessary: for example, in MessageSourceAccessor. DispatcherServlet automatically exposes its current Locale here. Other applications can expose theirs too, to make classes like MessageSourceAccessor automatically use that Locale.
• MessageSourceAware: Interface to be implemented by any object that wishes to be notified of the MessageSource (typically the ApplicationContext) that it runs in. Note that the MessageSource can usually also be passed on as bean reference (to arbitrary bean properties or constructor arguments), because it is defined as bean with name "messageSource" in the application context.
• 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.
• ConfigurableApplicationContext: SPI interface to be implemented by most if not all application contexts. Provides means to configure an application context in addition to the application context client methods in the ApplicationContext interface. Configuration and lifecycle methods are encapsulated here to avoid making them obvious to ApplicationContext client code.
• ContextBeanFactoryReference: ApplicationContext-specific implementation of BeanFactoryReference, wrapping a newly created ApplicationContext, closing it on release. As per BeanFactoryReference contract, release may be called more than once, with subsequent calls not doing anything. However, callging getFactory after a release call will cause an exception.
• EventPublicationInterceptor: Interceptor that knows how to publish ApplicationEvents to all ApplicationListeners registered with an ApplicationEventPublisher (typically an ApplicationContext). Note that this interceptor is only capable of publishing stateless events configured statically via the "applicationEventClass" property.
• 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.
| Home | Contact Us | Privacy Policy | Terms of Service |