Skip to content

Commit ef72baa

Browse files
committed
Revised @AspectJ vs XML section
Issue: SPR-17597
1 parent 14e87d2 commit ef72baa

File tree

1 file changed

+9
-10
lines changed

1 file changed

+9
-10
lines changed

src/docs/asciidoc/core/core-aop.adoc

Lines changed: 9 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -2536,20 +2536,19 @@ There are various tradeoffs to consider.
25362536
The XML style may most familiar to existing Spring users, and it is backed by genuine
25372537
POJOs. When using AOP as a tool to configure enterprise services, XML can be a good
25382538
choice (a good test is whether you consider the pointcut expression to be a part of your
2539-
configuration that you might want to change independently). With the XML style, it is arguably
2540-
clearer from your configuration what aspects are present in the system.
2539+
configuration that you might want to change independently). With the XML style, it is
2540+
arguably clearer from your configuration which aspects are present in the system.
25412541

25422542
The XML style has two disadvantages. First, it does not fully encapsulate the
25432543
implementation of the requirement it addresses in a single place. The DRY principle says
25442544
that there should be a single, unambiguous, authoritative representation of any piece of
2545-
knowledge within a system. When using the XML style, the knowledge of how a
2546-
requirement is implemented is split across the declaration of the backing bean class
2547-
and the XML in the configuration file. When you use the @AspectJ style, this information
2548-
is encapsulated in a single single module: the aspect. Secondly, the XML style
2549-
is slightly more limited in what it can express than the @AspectJ style: Only the
2550-
"`singleton`" aspect instantiation model is supported, and it is not possible to combine
2551-
named pointcuts declared in XML. For example, in the @AspectJ style you can write
2552-
something like the following:
2545+
knowledge within a system. When using the XML style, the knowledge of how a requirement
2546+
is implemented is split across the declaration of the backing bean class and the XML in
2547+
the configuration file. When you use the @AspectJ style, this information is encapsulated
2548+
in a single module: the aspect. Secondly, the XML style is slightly more limited in what
2549+
it can express than the @AspectJ style: Only the "`singleton`" aspect instantiation model
2550+
is supported, and it is not possible to combine named pointcuts declared in XML.
2551+
For example, in the @AspectJ style you can write something like the following:
25532552

25542553
====
25552554
[source,java,indent=0]

0 commit comments

Comments
 (0)