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