Polishing
This commit is contained in:
@@ -103,13 +103,13 @@ The `MethodMatcher` interface is normally more important. The complete interface
|
||||
The `matches(Method, Class)` method is used to test whether this pointcut ever
|
||||
matches a given method on a target class. This evaluation can be performed when an AOP
|
||||
proxy is created to avoid the need for a test on every method invocation. If the
|
||||
two-argument `matches` method returns `true` for a given method, and the `isRuntime()` method
|
||||
for the MethodMatcher returns `true`, the three-argument matches method is invoked on
|
||||
every method invocation. This lets a pointcut look at the arguments passed to the
|
||||
method invocation immediately before the target advice starts.
|
||||
two-argument `matches` method returns `true` for a given method, and the `isRuntime()`
|
||||
method for the MethodMatcher returns `true`, the three-argument matches method is
|
||||
invoked on every method invocation. This lets a pointcut look at the arguments passed
|
||||
to the method invocation immediately before the target advice starts.
|
||||
|
||||
Most `MethodMatcher` implementations are static, meaning that their `isRuntime()` method returns `false`.
|
||||
In this case, the three-argument `matches` method is never invoked.
|
||||
Most `MethodMatcher` implementations are static, meaning that their `isRuntime()` method
|
||||
returns `false`. In this case, the three-argument `matches` method is never invoked.
|
||||
|
||||
TIP: If possible, try to make pointcuts static, allowing the AOP framework to cache the
|
||||
results of pointcut evaluation when an AOP proxy is created.
|
||||
@@ -145,20 +145,20 @@ See the <<aop, previous chapter>> for a discussion of supported AspectJ pointcut
|
||||
[[aop-api-pointcuts-impls]]
|
||||
=== Convenience Pointcut Implementations
|
||||
|
||||
Spring provides several convenient pointcut implementations. You can use some of them directly.
|
||||
Others are intended to be subclassed in application-specific pointcuts.
|
||||
Spring provides several convenient pointcut implementations. You can use some of them
|
||||
directly; others are intended to be subclassed in application-specific pointcuts.
|
||||
|
||||
|
||||
[[aop-api-pointcuts-static]]
|
||||
==== Static Pointcuts
|
||||
|
||||
Static pointcuts are based on the method and the target class and cannot take into account the
|
||||
method's arguments. Static pointcuts suffice -- and are best -- for most usages.
|
||||
Spring can evaluate a static pointcut only once, when a method is first
|
||||
invoked. After that, there is no need to evaluate the pointcut again with each method
|
||||
invocation.
|
||||
Static pointcuts are based on the method and the target class and cannot take into account
|
||||
the method's arguments. Static pointcuts suffice -- and are best -- for most usages.
|
||||
Spring can evaluate a static pointcut only once, when a method is first invoked.
|
||||
After that, there is no need to evaluate the pointcut again with each method invocation.
|
||||
|
||||
The rest of this section describes some of the static pointcut implementations that are included with Spring.
|
||||
The rest of this section describes some of the static pointcut implementations that are
|
||||
included with Spring.
|
||||
|
||||
[[aop-api-pointcuts-regex]]
|
||||
===== Regular Expression Pointcuts
|
||||
@@ -168,9 +168,9 @@ frameworks besides Spring make this possible.
|
||||
`org.springframework.aop.support.JdkRegexpMethodPointcut` is a generic regular
|
||||
expression pointcut that uses the regular expression support in the JDK.
|
||||
|
||||
With the `JdkRegexpMethodPointcut` class, you can provide a list of pattern strings. If
|
||||
any of these is a match, the pointcut evaluates to `true`. (So, the result is
|
||||
effectively the union of these pointcuts.)
|
||||
With the `JdkRegexpMethodPointcut` class, you can provide a list of pattern strings.
|
||||
If any of these is a match, the pointcut evaluates to `true`. (As a consequence,
|
||||
the resulting pointcut is effectively the union of the specified patterns.)
|
||||
|
||||
The following example shows how to use `JdkRegexpMethodPointcut`:
|
||||
|
||||
|
||||
@@ -1649,7 +1649,7 @@ join point, unless you specify otherwise, the order of execution is undefined. Y
|
||||
control the order of execution by specifying precedence. This is done in the normal
|
||||
Spring way by either implementing the `org.springframework.core.Ordered` interface in
|
||||
the aspect class or annotating it with the `@Order` annotation. Given two aspects, the
|
||||
aspect returning the lower value from `Ordered.getValue()` (or the annotation value) has
|
||||
aspect returning the lower value from `Ordered.getOrder()` (or the annotation value) has
|
||||
the higher precedence.
|
||||
|
||||
[NOTE]
|
||||
@@ -2918,7 +2918,7 @@ an aspect weaving phase to your build script.
|
||||
If you have chosen to use Spring AOP, you have a choice of @AspectJ or XML style.
|
||||
There are various tradeoffs to consider.
|
||||
|
||||
The XML style may most familiar to existing Spring users, and it is backed by genuine
|
||||
The XML style may be most familiar to existing Spring users, and it is backed by genuine
|
||||
POJOs. When using AOP as a tool to configure enterprise services, XML can be a good
|
||||
choice (a good test is whether you consider the pointcut expression to be a part of your
|
||||
configuration that you might want to change independently). With the XML style, it is
|
||||
|
||||
@@ -42,7 +42,7 @@ information on using the `BeanFactory` instead of the `ApplicationContext,` see
|
||||
|
||||
In Spring, the objects that form the backbone of your application and that are managed
|
||||
by the Spring IoC container are called beans. A bean is an object that is
|
||||
instantiated, assembled, and otherwise managed by a Spring IoC container. Otherwise, a
|
||||
instantiated, assembled, and managed by a Spring IoC container. Otherwise, a
|
||||
bean is simply one of many objects in your application. Beans, and the dependencies
|
||||
among them, are reflected in the configuration metadata used by a container.
|
||||
|
||||
@@ -2125,7 +2125,7 @@ startup, because it must satisfy the singleton's dependencies. The lazy-initiali
|
||||
is injected into a singleton bean elsewhere that is not lazy-initialized.
|
||||
|
||||
You can also control lazy-initialization at the container level by using the
|
||||
`default-lazy-init` attribute on the `<beans/>` element, a the following example shows:
|
||||
`default-lazy-init` attribute on the `<beans/>` element, as the following example shows:
|
||||
|
||||
[source,xml,indent=0,subs="verbatim,quotes"]
|
||||
----
|
||||
@@ -4429,7 +4429,8 @@ which these `BeanFactoryPostProcessor` instances run by setting the `order` prop
|
||||
However, you can only set this property if the `BeanFactoryPostProcessor` implements the
|
||||
`Ordered` interface. If you write your own `BeanFactoryPostProcessor`, you should
|
||||
consider implementing the `Ordered` interface, too. See the javadoc of the
|
||||
{api-spring-framework}/beans/factory/config/BeanFactoryPostProcessor.html[`BeanFactoryPostProcessor`] and {api-spring-framework}/core/Ordered.html[`Ordered`] interfaces for more details.
|
||||
{api-spring-framework}/beans/factory/config/BeanFactoryPostProcessor.html[`BeanFactoryPostProcessor`]
|
||||
and {api-spring-framework}/core/Ordered.html[`Ordered`] interfaces for more details.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
Reference in New Issue
Block a user