| Interface that describes the logical view of a set of
BeanDefinition BeanDefinitions and
BeanReference BeanReferences as presented in some configuration context.
With the introduction of
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
BeanDefinition BeanDefinitions and
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
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
BeanDefinition BeanDefinitions in the
org.springframework.beans.factory.BeanFactory back to the configuration data in a way
that has concrete meaning to the end user. As such,
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
org.springframework.beans.factory.parsing.ReaderEventListener subscribe to these events ,
allowing for a user-centric view of the bean metadata.
Each ComponentDefinition has a
ComponentDefinition.getSource source object which is configuration-specific.
In the case of XML-based configuration this is typically the
org.w3c.dom.Node which contains the user
supplied configuration information. In addition to this, each
BeanDefinition enclosed in a
ComponentDefinition has its own
BeanDefinition.getSource source object which may point
to a different, more specific, set of configuration data. Beyond this, individual pieces of bean metadata such
as the
org.springframework.beans.PropertyValue PropertyValues may also have a source object giving an
even greater level of detail. Source object extraction is handled through the
org.springframework.beans.factory.parsing.SourceExtractor which can be customized as required.
Whilst direct access to important
BeanReference BeanReferences is provided through
ComponentDefinition.getBeanReferences , tools may wish to inspect all
BeanDefinition BeanDefinitions to gather
the full set of
BeanReference BeanReferences . Implementations are required to provide
all
BeanReference BeanReferences that are required to validate the configuration of the
overall logical entity as well as those required to provide full user visualisation of the configuration.
It is expected that certain
BeanReference BeanReferences will not be important to
validation or to the user view of the configuration and as such these may be ommitted. A tool may wish to
display any additional
BeanReference BeanReferences sourced through the supplied
BeanDefinition BeanDefinitions but this is not considered to be a typical case.
Tools can determine the important of contained
BeanDefinition BeanDefinitions by checking the
BeanDefinition.getRole role identifier . The role is essentially a hint to the tool as to how
important the configuration provider believes a
BeanDefinition is to the end user. It is expected
that tools will not display all
BeanDefinition BeanDefinitions for a given
ComponentDefinition choosing instead to filter based on the role. Tools may choose to make
this filtering user configurable. Particular notice should be given to the
BeanDefinition.ROLE_INFRASTRUCTURE INFRASTRUCTURE role identifier .
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 Also: AbstractComponentDefinition
See Also: CompositeComponentDefinition
See Also: BeanComponentDefinition
See Also: ReaderEventListener.componentRegistered(ComponentDefinition) |