Fix broken cross-references in reference manual
This commit is contained in:
parent
401bcd4a8a
commit
a89c0ecf5d
|
@ -185,13 +185,13 @@ style.
|
|||
Spring AOP defaults to using standard JDK __dynamic proxies__ for AOP proxies. This
|
||||
enables any interface (or set of interfaces) to be proxied.
|
||||
|
||||
Spring AOP can also use CGLIB proxies. This is necessary to proxy classes, rather than
|
||||
Spring AOP can also use CGLIB proxies. This is necessary to proxy classes rather than
|
||||
interfaces. CGLIB is used by default if a business object does not implement an
|
||||
interface. As it is good practice to program to interfaces rather than classes, business
|
||||
interface. As it is good practice to program to interfaces rather than classes; business
|
||||
classes normally will implement one or more business interfaces. It is possible to
|
||||
<<aop-autoproxy-force-CGLIB,force the use of CGLIB>>, in those (hopefully rare) cases
|
||||
where you need to advise a method that is not declared on an interface, or where you
|
||||
need to pass a proxied object to a method as a concrete type.
|
||||
<<aop-proxying,force the use of CGLIB>>, in those (hopefully rare) cases where you
|
||||
need to advise a method that is not declared on an interface, or where you need to
|
||||
pass a proxied object to a method as a concrete type.
|
||||
|
||||
It is important to grasp the fact that Spring AOP is __proxy-based__. See
|
||||
<<aop-understanding-aop-proxies>> for a thorough examination of exactly what this
|
||||
|
@ -259,8 +259,8 @@ element:
|
|||
<aop:aspectj-autoproxy/>
|
||||
----
|
||||
|
||||
This assumes that you are using schema support as described in <<xsd-config>>. See
|
||||
<<xsd-config-body-schemas-aop>> for how to import the tags in the aop namespace.
|
||||
This assumes that you are using schema support as described in <<xsd-configuration>>. See
|
||||
<<xsd-config-body-schemas-aop>> for how to import the tags in the `aop` namespace.
|
||||
|
||||
|
||||
|
||||
|
@ -1546,8 +1546,8 @@ the new __syntax__ and refer the reader to the discussion in the previous sectio
|
|||
of advice parameters.
|
||||
|
||||
To use the aop namespace tags described in this section, you need to import the
|
||||
spring-aop schema as described in <<xsd-config>>. See <<xsd-config-body-schemas-aop>>
|
||||
for how to import the tags in the aop namespace.
|
||||
`spring-aop` schema as described in <<xsd-configuration>>. See <<xsd-config-body-schemas-aop>>
|
||||
for how to import the tags in the `aop` namespace.
|
||||
|
||||
Within your Spring configurations, all aspect and advisor elements must be placed within
|
||||
an `<aop:config>` element (you can have more than one `<aop:config>` element in an
|
||||
|
|
|
@ -1591,7 +1591,7 @@ The above configuration is equivalent to the following Java code:
|
|||
The p-namespace enables you to use the `bean` element's attributes, instead of nested
|
||||
`<property/>` elements, to describe your property values and/or collaborating beans.
|
||||
|
||||
Spring supports extensible configuration formats <<xsd-config,with namespaces>>, which are
|
||||
Spring supports extensible configuration formats <<xsd-configuration,with namespaces>>, which are
|
||||
based on an XML Schema definition. The `beans` configuration format discussed in this
|
||||
chapter is defined in an XML Schema document. However, the p-namespace is not defined in
|
||||
an XSD file and exists only in the core of Spring.
|
||||
|
@ -2549,7 +2549,7 @@ understand the "why" as well as the "how" behind it.
|
|||
|
||||
To create such a proxy, you insert a child `<aop:scoped-proxy/>` element into a scoped
|
||||
bean definition. See <<beans-factory-scopes-other-injection-proxies>> and
|
||||
<<xsd-config>>.) Why do definitions of beans scoped at the `request`, `session`,
|
||||
<<xsd-configuration>>.) Why do definitions of beans scoped at the `request`, `session`,
|
||||
`globalSession` and custom-scope levels require the `<aop:scoped-proxy/>` element ?
|
||||
Let's examine the following singleton bean definition and contrast it with what you need
|
||||
to define for the aforementioned scopes. (The following `userPreferences` bean
|
||||
|
@ -3493,7 +3493,7 @@ you write your own `BeanPostProcessor` you should consider implementing the `Ord
|
|||
interface too. For further details, consult the javadocs of the `BeanPostProcessor` and
|
||||
`Ordered` interfaces. See also the note below on
|
||||
<<beans-factory-programmatically-registering-beanpostprocessors, programmatic
|
||||
registration of `BeanPostProcessors`>>
|
||||
registration of `BeanPostProcessors`>>.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
@ -3537,11 +3537,11 @@ interface, clearly indicating the post-processor nature of that bean. Otherwise,
|
|||
Since a ++BeanPostProcessor++ needs to be instantiated early in order to apply to the
|
||||
initialization of other beans in the context, this early type detection is critical.
|
||||
|
||||
|
||||
[[beans-factory-programmatically-registering-beanpostprocessors]]
|
||||
.Programmatically registering BeanPostProcessors
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
*Programmatically registering BeanPostProcessors*
|
||||
|
||||
While the recommended approach for `BeanPostProcessor` registration is through
|
||||
`ApplicationContext` auto-detection (as described above), it is also possible to
|
||||
register them __programmatically__ against a `ConfigurableBeanFactory` using the
|
||||
|
@ -3554,11 +3554,9 @@ programmatically are always processed before those registered through auto-detec
|
|||
regardless of any explicit ordering.
|
||||
====
|
||||
|
||||
.BeanPostProcessors and AOP auto-proxying
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
*BeanPostProcessors and AOP auto-proxying*
|
||||
|
||||
Classes that implement the `BeanPostProcessor` interface are __special__ and are treated
|
||||
differently by the container. All `BeanPostProcessors` __and beans that they reference
|
||||
directly__ are instantiated on startup, as part of the special startup phase of the
|
||||
|
|
|
@ -306,7 +306,7 @@ infrastructure.
|
|||
[NOTE]
|
||||
====
|
||||
The above definition of the `dataSource` bean uses the `<jndi-lookup/>` tag from the
|
||||
`jee` namespace. For more information on schema-based configuration, see <<xsd-config>>,
|
||||
`jee` namespace. For more information on schema-based configuration, see <<xsd-configuration>>,
|
||||
and for more information on the `<jee/>` tags see the section entitled
|
||||
<<xsd-config-body-schemas-jee>>.
|
||||
====
|
||||
|
|
|
@ -6172,26 +6172,27 @@ Spring distribution. In all likelihood, you shouldn't ever need to implement you
|
|||
This implementation does not reuse any threads, rather it starts up a new thread
|
||||
for each invocation. However, it does support a concurrency limit which will block
|
||||
any invocations that are over the limit until a slot has been freed up. If you
|
||||
re looking for true pooling, keep scrolling further down the page.
|
||||
are looking for true pooling, see the discussions of `SimpleThreadPoolTaskExecutor`
|
||||
and `ThreadPoolTaskExecutor` below.
|
||||
* `SyncTaskExecutor`
|
||||
This implementation doesn't execute invocations asynchronously. Instead, each
|
||||
invocation takes place in the calling thread. It is primarily used in situations
|
||||
where multi-threading isn't necessary such as simple test cases.
|
||||
* `ConcurrentTaskExecutor`
|
||||
This implementation is an adapter for a `java.util.concurrent.Executor` object.
|
||||
There is an alternative, `ThreadPoolTaskExecutor, that exposes the `Executor`
|
||||
There is an alternative, `ThreadPoolTaskExecutor`, that exposes the `Executor`
|
||||
configuration parameters as bean properties. It is rare to need to use the
|
||||
`ConcurrentTaskExecutor` but if the <<threadPoolTaskExecutor, `ThreadPoolTaskExecutor`>>
|
||||
isn't flexible enough for your needs, the `ConcurrentTaskExecutor` is an alternative.
|
||||
`ConcurrentTaskExecutor`, but if the `ThreadPoolTaskExecutor` isn't flexible
|
||||
enough for your needs, the `ConcurrentTaskExecutor` is an alternative.
|
||||
* `SimpleThreadPoolTaskExecutor`
|
||||
This implementation is actually a subclass of Quartz's `SimpleThreadPool` which
|
||||
listens to Spring's lifecycle callbacks. This is typically used when you have a
|
||||
thread pool that may need to be shared by both Quartz and non-Quartz components.
|
||||
* `ThreadPoolTaskExecutor`
|
||||
This implementation is the most commonly used one. It exposes bean properties for
|
||||
configuring a java.util.concurrent.ThreadPoolExecutor` and wraps it in a `TaskExecutor`.
|
||||
configuring a `java.util.concurrent.ThreadPoolExecutor` and wraps it in a `TaskExecutor`.
|
||||
If you need to adapt to a different kind of `java.util.concurrent.Executor`, it is
|
||||
recommended that you use a <<concurrentTaskExecutor, `ConcurrentTaskExecutor`>> instead.
|
||||
recommended that you use a `ConcurrentTaskExecutor` instead.
|
||||
* `WorkManagerTaskExecutor`
|
||||
|
||||
+
|
||||
|
@ -6204,11 +6205,10 @@ Application Server implementations.
|
|||
|
||||
+
|
||||
|
||||
This implementation uses the CommonJ WorkManager as its backing implementation and is
|
||||
the central convenience class for setting up a CommonJ WorkManager reference in a Spring
|
||||
context. Similar to the <<simpleThreadPoolTaskExecutor, `SimpleThreadPoolTaskExecutor`>>,
|
||||
this class implements the WorkManager interface and therefore can be used directly as a
|
||||
WorkManager as well.
|
||||
This implementation uses the CommonJ `WorkManager` as its backing implementation and is
|
||||
the central convenience class for setting up a CommonJ `WorkManager` reference in a Spring
|
||||
context. Similar to the `SimpleThreadPoolTaskExecutor`, this class implements the
|
||||
`WorkManager` interface and therefore can be used directly as a `WorkManager` as well.
|
||||
|
||||
|
||||
|
||||
|
@ -7121,7 +7121,7 @@ container. Using the dynamic-language-backed beans with a plain `BeanFactory`
|
|||
implementation is supported, but you have to manage the plumbing of the Spring internals
|
||||
to do so.
|
||||
|
||||
For more information on schema-based configuration, see <<xsd-config>>.
|
||||
For more information on schema-based configuration, see <<xsd-configuration>>.
|
||||
====
|
||||
|
||||
[source,xml,indent=0]
|
||||
|
|
|
@ -263,7 +263,7 @@ XML configuration equivalent:
|
|||
----
|
||||
|
||||
The above is for use in Spring MVC applications and should be included in the
|
||||
configuration of a <<mvc-serlvet,DispatcherServlet>>. However, Spring's WebSocket
|
||||
configuration of a <<mvc-servlet,DispatcherServlet>>. However, Spring's WebSocket
|
||||
support does not depend on Spring MVC. It is relatively simple to integrate a `WebSocketHandler`
|
||||
into other HTTP serving environments with the help of
|
||||
{javadoc-baseurl}/org/springframework/web/socket/server/support/WebSocketHttpRequestHandler.html[WebSocketHttpRequestHandler].
|
||||
|
@ -731,7 +731,7 @@ and the XML configuration equivalent:
|
|||
----
|
||||
|
||||
The above is for use in Spring MVC applications and should be included in the
|
||||
configuration of a <<mvc-serlvet,DispatcherServlet>>. However, Spring's WebSocket
|
||||
configuration of a <<mvc-servlet,DispatcherServlet>>. However, Spring's WebSocket
|
||||
and SockJS support does not depend on Spring MVC. It is relatively simple to
|
||||
integrate into other HTTP serving environments with the help of
|
||||
{javadoc-baseurl}/org/springframework/web/socket/sockjs/support/SockJsHttpRequestHandler.html[SockJsHttpRequestHandler].
|
||||
|
|
Loading…
Reference in New Issue