The introduction of annotation-based configuration raised the question of whether this approach is “better” than XML. The short answer is “it depends.” The long answer is that each approach has its pros and cons, and, usually, it is up to the developer to decide which strategy suits them better. Due to the way they are defined, annotations provide a lot of context in their declaration, leading to shorter and more concise configuration. However, XML excels at wiring up components without touching their source code or recompiling them. Some developers prefer having the wiring close to the source while others argue that annotated classes are no longer POJOs and, furthermore, that the configuration becomes decentralized and harder to control.
No matter the choice, Spring can accommodate both styles and even mix them together. It is worth pointing out that through its JavaConfig option, Spring lets annotations be used in a non-invasive way, without touching the target components' source code and that, in terms of tooling, all configuration styles are supported by Spring Tools for Eclipse, Visual Studio Code, and Theia.
An alternative to XML setup is provided by annotation-based configuration, which relies
on bytecode metadata for wiring up components instead of XML declarations. Instead of
using XML to describe a bean wiring, the developer moves the configuration into the
component class itself by using annotations on the relevant class, method, or field
declaration. As mentioned in Example: The AutowiredAnnotationBeanPostProcessor
, using a
BeanPostProcessor
in conjunction with annotations is a common means of extending the
Spring IoC container. For example, the @Autowired
annotation provides the same capabilities as described in Autowiring Collaborators but
with more fine-grained control and wider applicability. In addition, Spring provides
support for JSR-250 annotations, such as @PostConstruct
and @PreDestroy
, as well as
support for JSR-330 (Dependency Injection for Java) annotations contained in the
jakarta.inject
package such as @Inject
and @Named
. Details about those annotations
can be found in the relevant section.
Note
|
Annotation injection is performed before XML injection. Thus, the XML configuration overrides the annotations for properties wired through both approaches. |
As always, you can register the post-processors as individual bean definitions, but they
can also be implicitly registered by including the following tag in an XML-based Spring
configuration (notice the inclusion of the context
namespace):
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans
https://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
https://www.springframework.org/schema/context/spring-context.xsd">
<context:annotation-config/>
</beans>
The <context:annotation-config/>
element implicitly registers the following post-processors:
-
{api-spring-framework}/context/annotation/ConfigurationClassPostProcessor.html[
ConfigurationClassPostProcessor
] -
{api-spring-framework}/beans/factory/annotation/AutowiredAnnotationBeanPostProcessor.html[
AutowiredAnnotationBeanPostProcessor
] -
{api-spring-framework}/context/annotation/CommonAnnotationBeanPostProcessor.html[
CommonAnnotationBeanPostProcessor
] -
{api-spring-framework}/orm/jpa/support/PersistenceAnnotationBeanPostProcessor.html[
PersistenceAnnotationBeanPostProcessor
] -
{api-spring-framework}/context/event/EventListenerMethodProcessor.html[
EventListenerMethodProcessor
]
Note
|
|