public interface ComponentDefinition extends BeanMetadataElement
BeanReferencesas presented in some configuration context.
With the introduction of
pluggable custom XML tags,
it is now possible for a single logical configuration entity, in this case an XML tag, to
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
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
BeanFactory back to the configuration data in a way
that has concrete meaning to the end user. As such,
implementations are able to publish events in the form of a
ComponentDefinition for each
logical entity being configured. Third parties can then
subscribe to these events,
allowing for a user-centric view of the bean metadata.
ComponentDefinition has a
source object which is configuration-specific.
In the case of XML-based configuration this is typically the <code>Node</code> which contains the user
supplied configuration information. In addition to this, each
BeanDefinition enclosed in a
ComponentDefinition has its own
source object which may point
to a different, more specific, set of configuration data. Beyond this, individual pieces of bean metadata such
PropertyValues may also have a source object giving an
even greater level of detail. Source object extraction is handled through the
SourceExtractor which can be customized as required.
Whilst direct access to important
BeanReferences is provided through
getBeanReferences(), tools may wish to inspect all
BeanDefinitions to gather
the full set of
BeanReferences. Implementations are required to provide
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
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
BeanReferences sourced through the supplied
BeanDefinitions but this is not considered to be a typical case.
Tools can determine the important of contained
BeanDefinitions by checking the
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
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
INFRASTRUCTURE role identifier.
classified with this role are completely unimportant to the end user and are required only for
internal implementation reasons.
|Modifier and Type||Method and Description|
Return the set of
Return a friendly description of the described component.
Get the user-visible name of this
This should link back directly to the corresponding configuration data for this component in a given context.
Implementations are encouraged to return the same value from
BeanDefinitionsthat were registered to form this
It should be noted that a
ComponentDefinition may well be related with
however these are not included as they may be not available immediately.
BeanReferences are available from
BeanDefinitionsthat represent all relevant inner beans within this component.
Other inner beans may exist within the associated
however these are not considered to be needed for validation or for user visualization.
BeanReferencesthat are considered to be important to this