Home >> All >> org >> springframework >> beans >> factory >> [ support Javadoc ]

• org.springframework.beans.factory.support: Javadoc index of package org.springframework.beans.factory.support.


Package Samples:

• org.springframework.beans.factory.support

Classes:

• AbstractAutowireCapableBeanFactory: Abstract BeanFactory superclass that implements default bean creation, with the full capabilities specified by the RootBeanDefinition class. Implements the AutowireCapableBeanFactory interface. Like the base class AbstractBeanFactory, this superclass does not assume a listable bean factory. Provides bean creation (with constructor resolution), property population, wiring (including autowiring), and initialization. Handles runtime bean references, resolves managed collections, calls initialization methods, etc. Supports autowiring constructors, properties by name, and properties by type. The main ...
• AbstractBeanFactory: Abstract superclass for BeanFactory implementations, implementing the ConfigurableBeanFactory SPI interface. Does not assume a listable bean factory: can therefore also be used as base class for bean factory implementations which fetch bean definitions from a variety of backend resources (where bean definition access is an expensive operation). This class provides singleton/prototype determination, singleton cache, aliases, FactoryBean handling, bean definition merging for child bean definitions, and bean destruction (DisposableBean interface, custom destroy methods). Furthermore, it can manage ...
• PropertiesBeanDefinitionReader: Bean definition reader for a simple properties format. Provides bean definition registration methods for Map/Properties and ResourceBundle. Typically applied to a DefaultListableBeanFactory. Example: employee.class=MyClass // bean is of class MyClass employee.(abstract)=true // this bean can't be instantiated directly employee.group=Insurance // real property employee.usesDialUp=false // real property (potentially overridden) salesrep.parent=employee // derives from "employee" bean definition salesrep.(lazy-init)=true // lazily initialize this singleton bean salesrep.manager(ref)=tony // reference ...
• DefaultListableBeanFactory: Default implementation of the ListableBeanFactory and BeanDefinitionRegistry interfaces: a full-fledged bean factory based on bean definitions. Typical usage is registering all bean definitions first (possibly read from a bean definition file), before accessing beans. Bean definition lookup is therefore an inexpensive operation in a local bean definition table. Can be used as a standalone bean factory, or as a superclass for custom bean factories. Note that readers for specific bean definition formats are typically implemented separately rather than as bean factory subclasses. For an alternative ...
• ChildBeanDefinition: Bean definition for beans who inherit settings from their parent. Will use the bean class of the parent if none specified, but can also override it. In the latter case, the child bean class must be compatible with the parent, i.e. accept the parent's property values and constructor argument values, if any. A child bean definition will inherit constructor argument values, property values and method overrides from the parent, with the option to add new values. If init method, destroy method and/or static factory method are specified, they will override the corresponding parent settings. The remaining ...
• BeanDefinitionRegistry: Interface for registries that hold bean definitions, for example RootBeanDefinition and ChildBeanDefinition instances. Typically implemented by bean factories that internally work with the AbstractBeanDefinition hierarchy. This is the only interface in Spring's bean factory packages that encapsulates registration of bean definitions. The standard bean factory interfaces only cover access to a fully configured factory instance. Spring's bean definition readers expect to work on an implementation of this interface. Known implementors are DefaultListableBeanFactory and GenericApplicationContext, for ...
• BeanDefinitionReader: Simple interface for bean definition readers. Specifies load methods with Resource parameters. Concrete bean definition readers can of course add additional load and register methods for bean definitions, specific to their bean definition format. Note that a bean definition reader does not have to implement this interface. It only serves as suggestion for bean definition readers that want to follow standard naming conventions.
• RootBeanDefinition: Root bean definitions are the most common type of bean definition. They do not derive from a parent bean definition, and usually have a class plus optionally constructor argument values and property values. Note that root bean definitions do not have to specify a bean class: This can be useful for deriving childs from such definitions, each with its own bean class but inheriting common property values and other settings.
• StaticListableBeanFactory: Static factory that allows to register existing singleton instances programmatically. Does not have support for prototype beans and aliases. Serves as example for a simple implementation of the ListableBeanFactory interface, managing existing bean instances rather than creating new ones based on bean definitions. For a full-fledged bean factory based on bean definitions, have a look at DefaultListableBeanFactory.
• CglibSubclassingInstantiationStrategy: Default object instantiation strategy for use in BeanFactories. Uses CGLIB to generate subclasses dynamically if methods need to be overridden by the container, to implement Method Injection. Using Method Injection features requires CGLIB on the classpath. However, the core IoC container will still run without CGLIB being available.
• MethodReplacer: Interface to be implemented by classes that can reimplement any method on an IoC-managed object: the Method Injection form of Dependency Injection. Such methods may be (but need not be) abstract, in which case the container will create a concrete subclass to instantiate.
• InstantiationStrategy: Interface responsible for creating instances corresponding to a root bean definition. This is pulled out into a strategy as various approaches are possible, including using CGLIB to create subclasses on the fly to support Method Injection.
• ManagedMap: Tag collection class used to hold managed Map values, which may include runtime bean references. Wraps a target Map, which will be a linked map if possible (that is, if running on JDK 1.4 or if Commons Collections 3.x is available).
• ManagedSet: Tag collection class used to hold managed Set values, which may include runtime bean references. Wraps a target Set, which will be a linked set if possible (that is, if running on JDK 1.4 or if Commons Collections 3.x is available).
• AbstractBeanDefinition: Base class for bean definition objects, factoring out common properties of RootBeanDefinition and ChildBeanDefinition. The autowire constants match the ones defined in the AutowireCapableBeanFactory interface, adding AUTOWIRE_NO.
• SimpleInstantiationStrategy: Simple object instantiation strategy for use in a BeanFactory. Does not support Method Injection, although it provides hooks for subclasses to override to add Method Injection support, for example by overriding methods.
• MethodOverrides: Set of method overrides, determining which, if any, methods on a managed object the Spring IoC container will override at runtime. The currently supported MethodOverride variants are LookupOverride and ReplaceOverride.
• AbstractBeanDefinitionReader: Abstract base class for bean definition readers which implement the BeanDefinitionReader interface. Provides common properties like the bean factory to work on and the class loader to use for loading bean classes.
• MethodOverride: Object representing the override of a method on a managed object by the IoC container. Note that the override mechanism is not intended as a generic means of inserting crosscutting code: use AOP for that.
• ReplaceOverride: Extension of MethodOverride that represents an arbitrary override of a method by the IoC container. Any non-final method can be overridden, irrespective of its parameters and return types.
• LookupOverride: Represents an override of a method that looks up an object in the same IoC context. Methods eligible for lookup override must not have arguments.
• AutowireUtils: Utility class that contains various methods useful for the implementation of autowire-capable bean factories.

Home | Contact Us | Privacy Policy | Terms of Service