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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|