Similar to Spring 2.0's support for XML namespaces, JavaConfig provides an
extensibility mechanism with the @Plugin annotation. The general
intent is to allow for a more expressive and declarative way to register commonly
used bean definitions.
To get a sense of what @Plugin can do, consider each of the following
annotations already discussed in this document:
@AnnotationDrivenConfig, @AnnotationDrivenTx,
@MBeanExport, @PropertiesValueSource. These annotations
are all "@Plugin annotations". Take AnnotationDrivenConfig
for example:
@Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE) @Documented @Plugin(handler=AnnotationDrivenConfigHandler.class) public @interface AnnotationDrivenConfig { }
@AnnotationDrivenConfig is 'meta-annotated' as @Plugin.
Notice the handler attribute to @Plugin accepts
AnnotationDrivenConfigHandler.class:
class AnnotationDrivenConfigHandler implements ConfigurationPlugin<AnnotationDrivenConfig> { public void handle(AnnotationDrivenConfig annotation, BeanDefinitionRegistry registry) { AnnotationConfigUtils.registerAnnotationConfigProcessors(registry); } }
The handle method of any ConfigurationPlugin
implementation is provided with the annotation
(AnnotationDrivenConfig in this case), as well as a
BeanDefinitionRegistry - this registry is the same registry that JavaConfig
is using to register all objects created from @Bean methods.
Therefore, ConfigurationPlugin implementations have direct control over
the container and can do with it as they please. Any number and type of bean
definitions may be registered, offloading tedious or repetitive work from the
@Configuration class author.
![]() | Note |
|---|---|
This documentation is preliminary and the @Plugin/
ConfigurationPlugin API may change before JavaConfig's GA
release. To find out more about programming @Plugin
annotations, study the existing set of annotations mentioned above,
and don't hesitate to interact with us via the
JavaConfig forum.
|