The following features are supported:
A component is a configured instance of an implementation. The services provided and consumed and the available configuration properties are defined by the implementation (represented by its componentType).
Every component has a name which uniquely identifies it within the scope of the composite that contains it; the name must be different from the names of all other components, services and references immediately contained in the composite (directly or through an <include> element).
A component may define a {@link PropertyValue} that overrides the default value of a {@link Property}defined in the componentType.
It may also define a {@link ReferenceTarget} for a {@link ReferenceDefinition} defined in the componentType.The ReferenceTarget must resolve to another component or a reference in the enclosing composite.
Components may specify an initialization level that will determine the order in which it will be eagerly initialized relative to other components from the enclosing composite that are in the same scope. This can be used to define a startup sequence for components that are otherwise independent. Any initialization required to resolve references between components will override this initialization order.
@version $Rev: 430937 $ $Date: 2006-08-11 18:17:56 -0700 (Fri, 11 Aug 2006) $With the introduction of {@link org.springframework.beans.factory.xml.NamespaceHandler pluggable custom XML tags}, it is now possible for a single logical configuration entity, in this case an XML tag, to create multiple {@link BeanDefinition BeanDefinitions} and {@link BeanReference RuntimeBeanReferences}in order to provide more succinct configuration and greater convenience to end users. As such, it can no longer be assumed that each configuration entity (e.g. XML tag) maps to one {@link BeanDefinition}. For tool vendors and other users who wish to present visualization or support for configuring Spring applications it is important that there is some mechanism in place to tie the {@link BeanDefinition BeanDefinitions}in the {@link org.springframework.beans.factory.BeanFactory} back to the configuration data in a waythat has concrete meaning to the end user. As such, {@link org.springframework.beans.factory.xml.NamespaceHandler}implementations are able to publish events in the form of a ComponentDefinition for each logical entity being configured. Third parties can then {@link org.springframework.beans.factory.parsing.ReaderEventListener subscribe to these events}, allowing for a user-centric view of the bean metadata.
Each ComponentDefinition has a {@link #getSource source object} which is configuration-specific.In the case of XML-based configuration this is typically the {@link org.w3c.dom.Node} which contains the usersupplied configuration information. In addition to this, each {@link BeanDefinition} enclosed in aComponentDefinition has its own {@link BeanDefinition#getSource() source object} which may pointto a different, more specific, set of configuration data. Beyond this, individual pieces of bean metadata such as the {@link org.springframework.beans.PropertyValue PropertyValues} may also have a source object giving aneven greater level of detail. Source object extraction is handled through the {@link org.springframework.beans.factory.parsing.SourceExtractor} which can be customized as required.
Whilst direct access to important {@link BeanReference BeanReferences} is provided through{@link #getBeanReferences}, tools may wish to inspect all {@link BeanDefinition BeanDefinitions} to gatherthe full set of {@link BeanReference BeanReferences}. Implementations are required to provide all {@link BeanReference BeanReferences} that are required to validate the configuration of theoverall logical entity as well as those required to provide full user visualisation of the configuration. It is expected that certain {@link BeanReference BeanReferences} will not be important tovalidation or to the user view of the configuration and as such these may be ommitted. A tool may wish to display any additional {@link BeanReference BeanReferences} sourced through the supplied{@link BeanDefinition BeanDefinitions} but this is not considered to be a typical case.
Tools can determine the important of contained {@link BeanDefinition BeanDefinitions} by checking the{@link BeanDefinition#getRole role identifier}. The role is essentially a hint to the tool as to how important the configuration provider believes a {@link BeanDefinition} is to the end user. It is expectedthat tools will not display all {@link BeanDefinition BeanDefinitions} for a givenComponentDefinition choosing instead to filter based on the role. Tools may choose to make this filtering user configurable. Particular notice should be given to the {@link BeanDefinition#ROLE_INFRASTRUCTURE INFRASTRUCTURE role identifier}. {@link BeanDefinition BeanDefinitions}classified with this role are completely unimportant to the end user and are required only for internal implementation reasons.
@author Rob Harrop
@author Juergen Hoeller
@since 2.0
@see AbstractComponentDefinition
@see CompositeComponentDefinition
@see BeanComponentDefinition
@see ReaderEventListener#componentRegistered(ComponentDefinition)
The implementation need NOT to be thread safe, since the caller has to {@link #clone} first if accessed concurrently. @author tomyeh
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |