Merge branch '6.2.x'
# Conflicts: # framework-docs/modules/ROOT/pages/core/null-safety.adoc # framework-docs/modules/ROOT/pages/core/validation/error-code-resolution.adoc # framework-docs/modules/ROOT/pages/integration/cds.adoc # framework-docs/modules/ROOT/pages/integration/jms/sending.adoc # framework-docs/modules/ROOT/pages/integration/rest-clients.adoc # framework-docs/modules/ROOT/pages/languages/kotlin/bean-definition-dsl.adoc # framework-docs/modules/ROOT/pages/languages/kotlin/null-safety.adoc # framework-docs/modules/ROOT/pages/languages/kotlin/web.adoc # framework-docs/modules/ROOT/pages/web/webflux/config.adoc # framework-docs/modules/ROOT/pages/web/webflux/controller/ann-requestmapping.adoc # framework-docs/modules/ROOT/pages/web/webmvc/mvc-http2.adoc
This commit is contained in:
Juergen Hoeller
commit
4ca8a8abbe
|
|
@ -6,7 +6,7 @@ nav:
|
|||
ext:
|
||||
collector:
|
||||
run:
|
||||
command: gradlew -q -PbuildSrc.skipTests=true "-Dorg.gradle.jvmargs=-Xmx3g -XX:+HeapDumpOnOutOfMemoryError" :framework-docs:generateAntoraResources
|
||||
command: gradlew -q -PbuildSrc.skipTests=true "-Dorg.gradle.jvmargs=-Xmx3g" :framework-docs:generateAntoraResources
|
||||
local: true
|
||||
scan:
|
||||
dir: ./build/generated-antora-resources
|
||||
|
|
|
|||
|
|
@ -17,14 +17,3 @@ is also provided.
|
|||
|
||||
AOT processing can be used to optimize your application ahead-of-time. It is typically
|
||||
used for native image deployment using GraalVM.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,3 @@ The previous chapter described the Spring's support for AOP with @AspectJ and sc
|
|||
aspect definitions. In this chapter, we discuss the lower-level Spring AOP APIs. For common
|
||||
applications, we recommend the use of Spring AOP with AspectJ pointcuts as described in the
|
||||
previous chapter.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@
|
|||
Now we can examine how Spring AOP handles advice.
|
||||
|
||||
|
||||
|
||||
[[aop-api-advice-lifecycle]]
|
||||
== Advice Lifecycles
|
||||
|
||||
|
|
@ -22,14 +21,12 @@ the advice adds state to the proxied object.
|
|||
You can use a mix of shared and per-instance advice in the same AOP proxy.
|
||||
|
||||
|
||||
|
||||
[[aop-api-advice-types]]
|
||||
== Advice Types in Spring
|
||||
|
||||
Spring provides several advice types and is extensible to support
|
||||
arbitrary advice types. This section describes the basic concepts and standard advice types.
|
||||
|
||||
|
||||
[[aop-api-advice-around]]
|
||||
=== Interception Around Advice
|
||||
|
||||
|
|
@ -101,7 +98,6 @@ you are likely to want to run the aspect in another AOP framework. Note that poi
|
|||
are not currently interoperable between frameworks, and the AOP Alliance does not
|
||||
currently define pointcut interfaces.
|
||||
|
||||
|
||||
[[aop-api-advice-before]]
|
||||
=== Before Advice
|
||||
|
||||
|
|
@ -168,7 +164,6 @@ Kotlin::
|
|||
|
||||
TIP: Before advice can be used with any pointcut.
|
||||
|
||||
|
||||
[[aop-api-advice-throws]]
|
||||
=== Throws Advice
|
||||
|
||||
|
|
@ -297,7 +292,6 @@ exception that is incompatible with the target method's signature!_
|
|||
|
||||
TIP: Throws advice can be used with any pointcut.
|
||||
|
||||
|
||||
[[aop-api-advice-after-returning]]
|
||||
=== After Returning Advice
|
||||
|
||||
|
|
@ -361,7 +355,6 @@ thrown up the interceptor chain instead of the return value.
|
|||
|
||||
TIP: After returning advice can be used with any pointcut.
|
||||
|
||||
|
||||
[[aop-api-advice-introduction]]
|
||||
=== Introduction Advice
|
||||
|
||||
|
|
@ -501,7 +494,6 @@ Java::
|
|||
}
|
||||
return super.invoke(invocation);
|
||||
}
|
||||
|
||||
}
|
||||
----
|
||||
|
||||
|
|
@ -531,7 +523,6 @@ Kotlin::
|
|||
}
|
||||
return super.invoke(invocation)
|
||||
}
|
||||
|
||||
}
|
||||
----
|
||||
======
|
||||
|
|
@ -582,8 +573,3 @@ We can apply this advisor programmatically by using the `Advised.addAdvisor()` m
|
|||
(the recommended way) in XML configuration, as any other advisor. All proxy creation
|
||||
choices discussed below, including "`auto proxy creators,`" correctly handle introductions
|
||||
and stateful mixins.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -142,7 +142,3 @@ case, the `Advised` `isFrozen()` method returns `true`, and any attempts to modi
|
|||
advice through addition or removal results in an `AopConfigException`. The ability
|
||||
to freeze the state of an advised object is useful in some cases (for example, to
|
||||
prevent calling code removing a security interceptor).
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,3 @@ It is possible to mix advisor and advice types in Spring in the same AOP proxy.
|
|||
example, you could use an interception around advice, throws advice, and before advice in
|
||||
one proxy configuration. Spring automatically creates the necessary interceptor
|
||||
chain.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -19,14 +19,12 @@ There are two ways to do this:
|
|||
auto-proxy creation driven by source-level metadata attributes.
|
||||
|
||||
|
||||
|
||||
[[aop-autoproxy-choices]]
|
||||
== Auto-proxy Bean Definitions
|
||||
|
||||
This section covers the auto-proxy creators provided by the
|
||||
`org.springframework.aop.framework.autoproxy` package.
|
||||
|
||||
|
||||
[[aop-api-autoproxy]]
|
||||
=== `BeanNameAutoProxyCreator`
|
||||
|
||||
|
|
@ -61,7 +59,6 @@ automatically created by the `BeanNameAutoProxyCreator`. The same advice is appl
|
|||
to all matching beans. Note that, if advisors are used (rather than the interceptor in
|
||||
the preceding example), the pointcuts may apply differently to different beans.
|
||||
|
||||
|
||||
[[aop-api-autoproxy-default]]
|
||||
=== `DefaultAdvisorAutoProxyCreator`
|
||||
|
||||
|
|
@ -125,7 +122,3 @@ differently configured, AdvisorAutoProxyCreators in the same factory) and orderi
|
|||
Advisors can implement the `org.springframework.core.Ordered` interface to ensure
|
||||
correct ordering if this is an issue. The `TransactionAttributeSourceAdvisor` used in the
|
||||
preceding example has a configurable order value. The default setting is unordered.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -65,7 +65,3 @@ that, if you have a (parent) bean definition that you intend to use only as a te
|
|||
and this definition specifies a class, you must make sure to set the `abstract`
|
||||
attribute to `true`. Otherwise, the application context actually tries to
|
||||
pre-instantiate it.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,6 @@ the pointcuts, any advice that applies, and their ordering. However, there are s
|
|||
options that are preferable if you do not need such control.
|
||||
|
||||
|
||||
|
||||
[[aop-pfb-1]]
|
||||
== Basics
|
||||
|
||||
|
|
@ -32,7 +31,6 @@ application objects (besides the target, which should be available in any AOP
|
|||
framework), benefiting from all the pluggability provided by Dependency Injection.
|
||||
|
||||
|
||||
|
||||
[[aop-pfb-2]]
|
||||
== JavaBean Properties
|
||||
|
||||
|
|
@ -87,7 +85,6 @@ to be applied. You can find an example of using this feature in xref:core/aop-ap
|
|||
`false`.
|
||||
|
||||
|
||||
|
||||
[[aop-pfb-proxy-types]]
|
||||
== JDK- and CGLIB-based proxies
|
||||
|
||||
|
|
@ -137,7 +134,6 @@ interface that the target class implements to the `proxyInterfaces` property. Ho
|
|||
it is significantly less work and less prone to typographical errors.
|
||||
|
||||
|
||||
|
||||
[[aop-api-proxying-intf]]
|
||||
== Proxying Interfaces
|
||||
|
||||
|
|
@ -263,7 +259,6 @@ However, there are times when being able to obtain the un-advised target from th
|
|||
factory might actually be an advantage (for example, in certain test scenarios).
|
||||
|
||||
|
||||
|
||||
[[aop-api-proxying-class]]
|
||||
== Proxying Classes
|
||||
|
||||
|
|
@ -302,7 +297,6 @@ There is little performance difference between CGLIB proxies and dynamic proxies
|
|||
Performance should not be a decisive consideration in this case.
|
||||
|
||||
|
||||
|
||||
[[aop-global-advisors]]
|
||||
== Using "`Global`" Advisors
|
||||
|
||||
|
|
@ -325,7 +319,3 @@ two global advisors:
|
|||
<bean id="global_debug" class="org.springframework.aop.interceptor.DebugInterceptor"/>
|
||||
<bean id="global_performance" class="org.springframework.aop.interceptor.PerformanceMonitorInterceptor"/>
|
||||
----
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@
|
|||
This section describes how Spring handles the crucial pointcut concept.
|
||||
|
||||
|
||||
|
||||
[[aop-api-concepts]]
|
||||
== Concepts
|
||||
|
||||
|
|
@ -69,7 +68,6 @@ TIP: If possible, try to make pointcuts static, allowing the AOP framework to ca
|
|||
results of pointcut evaluation when an AOP proxy is created.
|
||||
|
||||
|
||||
|
||||
[[aop-api-pointcut-ops]]
|
||||
== Operations on Pointcuts
|
||||
|
||||
|
|
@ -84,7 +82,6 @@ You can compose pointcuts by using the static methods in the
|
|||
expressions is usually a simpler approach.
|
||||
|
||||
|
||||
|
||||
[[aop-api-pointcuts-aspectj]]
|
||||
== AspectJ Expression Pointcuts
|
||||
|
||||
|
|
@ -95,14 +92,12 @@ uses an AspectJ-supplied library to parse an AspectJ pointcut expression string.
|
|||
See the xref:core/aop.adoc[previous chapter] for a discussion of supported AspectJ pointcut primitives.
|
||||
|
||||
|
||||
|
||||
[[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.
|
||||
|
||||
|
||||
[[aop-api-pointcuts-static]]
|
||||
=== Static Pointcuts
|
||||
|
||||
|
|
@ -146,7 +141,6 @@ You can use `RegexpMethodPointcutAdvisor` with any `Advice` type.
|
|||
An important type of static pointcut is a metadata-driven pointcut. This uses the
|
||||
values of metadata attributes (typically, source-level metadata).
|
||||
|
||||
|
||||
[[aop-api-pointcuts-dynamic]]
|
||||
=== Dynamic pointcuts
|
||||
|
||||
|
|
@ -172,7 +166,6 @@ other dynamic pointcuts. In Java 1.4, the cost is about five times that of other
|
|||
pointcuts.
|
||||
|
||||
|
||||
|
||||
[[aop-api-pointcuts-superclasses]]
|
||||
== Pointcut Superclasses
|
||||
|
||||
|
|
@ -214,7 +207,6 @@ There are also superclasses for dynamic pointcuts.
|
|||
You can use custom pointcuts with any advice type.
|
||||
|
||||
|
||||
|
||||
[[aop-api-pointcuts-custom]]
|
||||
== Custom Pointcuts
|
||||
|
||||
|
|
@ -225,7 +217,3 @@ expression language, if you can.
|
|||
|
||||
NOTE: Later versions of Spring may offer support for "`semantic pointcuts`" as offered by JAC --
|
||||
for example, "`all methods that change instance variables in the target object.`"
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,6 @@ rather than a singleton bean definition. This allows Spring to create a new targ
|
|||
instance when required.
|
||||
|
||||
|
||||
|
||||
[[aop-ts-swap]]
|
||||
== Hot-swappable Target Sources
|
||||
|
||||
|
|
@ -77,7 +76,6 @@ use a `TargetSource`), any `TargetSource` can be used in conjunction with
|
|||
arbitrary advice.
|
||||
|
||||
|
||||
|
||||
[[aop-ts-pool]]
|
||||
== Pooling Target Sources
|
||||
|
||||
|
|
@ -175,7 +173,6 @@ Simpler pooling is available by using auto-proxying. You can set the `TargetSour
|
|||
used by any auto-proxy creator.
|
||||
|
||||
|
||||
|
||||
[[aop-ts-prototype]]
|
||||
== Prototype Target Sources
|
||||
|
||||
|
|
@ -200,7 +197,6 @@ The only property is the name of the target bean. Inheritance is used in the
|
|||
source, the target bean must be a prototype bean definition.
|
||||
|
||||
|
||||
|
||||
[[aop-ts-threadlocal]]
|
||||
== `ThreadLocal` Target Sources
|
||||
|
||||
|
|
@ -226,7 +222,3 @@ always remember to correctly set and unset (where the latter involves a call to
|
|||
any case, since not unsetting it might result in problematic behavior. Spring's
|
||||
`ThreadLocal` support does this for you and should always be considered in favor of using
|
||||
`ThreadLocal` instances without other proper handling code.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,3 @@ AOP is used in the Spring Framework to:
|
|||
NOTE: If you are interested only in generic declarative services or other pre-packaged
|
||||
declarative middleware services such as pooling, you do not need to work directly with
|
||||
Spring AOP, and can skip most of this chapter.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -53,7 +53,3 @@ Kotlin::
|
|||
======
|
||||
|
||||
See the {spring-framework-api}/aop/aspectj/annotation/AspectJProxyFactory.html[javadoc] for more information.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -11,6 +11,3 @@ there is no dependency on the AspectJ compiler or weaver.
|
|||
|
||||
NOTE: Using the AspectJ compiler and weaver enables use of the full AspectJ language and
|
||||
is discussed in xref:core/aop/using-aspectj.adoc[Using AspectJ with Spring Applications].
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -937,5 +937,3 @@ reflection for javac-compiled classes). Consider collapsing such advice methods
|
|||
advice method per join point in each `@Aspect` class or refactor the pieces of advice into
|
||||
separate `@Aspect` classes that you can order at the aspect level via `Ordered` or `@Order`.
|
||||
====
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -32,6 +32,3 @@ stereotype annotation that qualifies, as per the rules of Spring's component sca
|
|||
NOTE: In Spring AOP, aspects themselves cannot be the targets of advice from other
|
||||
aspects. The `@Aspect` annotation on a class marks it as an aspect and, hence, excludes
|
||||
it from auto-proxying.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,8 @@ call `proceed` multiple times. The following listing shows the basic aspect impl
|
|||
|
||||
include-code::./ConcurrentOperationExecutor[tag=snippet,indent=0]
|
||||
|
||||
`@Around("com.xyz.CommonPointcuts.businessService()")` references the `businessService` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-common-pointcuts[Sharing Named Pointcut Definitions].
|
||||
`@Around("com.xyz.CommonPointcuts.businessService()")` references the `businessService` named pointcut defined in
|
||||
xref:core/aop/ataspectj/pointcuts.adoc#aop-common-pointcuts[Sharing Named Pointcut Definitions].
|
||||
|
||||
Note that the aspect implements the `Ordered` interface so that we can set the precedence of
|
||||
the aspect higher than the transaction advice (we want a fresh transaction each time we
|
||||
|
|
|
|||
|
|
@ -60,6 +60,3 @@ Programming Guide for more information on `per` clauses.
|
|||
|
||||
The `pertarget` instantiation model works in exactly the same way as `perthis`, but it
|
||||
creates one aspect instance for each unique target object at matched join points.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -75,5 +75,3 @@ Kotlin::
|
|||
val usageTracked = context.getBean<UsageTracked>("myService")
|
||||
----
|
||||
======
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -581,6 +581,3 @@ performance (time and memory used), due to extra processing and analysis. Scopin
|
|||
designators are very fast to match, and using them means AspectJ can very quickly
|
||||
dismiss groups of join points that should not be further processed. A good
|
||||
pointcut should always include one if possible.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,6 @@ decisions are influenced by a number of factors including application requiremen
|
|||
development tools, and team familiarity with AOP.
|
||||
|
||||
|
||||
|
||||
[[aop-spring-or-aspectj]]
|
||||
== Spring AOP or Full AspectJ?
|
||||
|
||||
|
|
@ -31,7 +30,6 @@ the @AspectJ style, sticking with regular Java compilation in your IDE, and addi
|
|||
an aspect weaving phase to your build script.
|
||||
|
||||
|
||||
|
||||
[[aop-ataspectj-or-xml]]
|
||||
== @AspectJ or XML for Spring AOP?
|
||||
|
||||
|
|
@ -107,7 +105,3 @@ Spring AOP and by AspectJ. So, if you later decide you need the capabilities of
|
|||
to implement additional requirements, you can easily migrate to a classic AspectJ setup.
|
||||
In general, the Spring team prefers the @AspectJ style for custom aspects beyond simple
|
||||
configuration of enterprise services.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -73,7 +73,3 @@ it from older technologies offering only interception. Pointcuts enable advice t
|
|||
targeted independently of the object-oriented hierarchy. For example, you can apply an
|
||||
around advice providing declarative transaction management to a set of methods that span
|
||||
multiple objects (such as all business operations in the service layer).
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -14,9 +14,5 @@ need to advise a method that is not declared on an interface or where you need t
|
|||
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
|
||||
xref:core/aop/proxying.adoc#aop-understanding-aop-proxies[Understanding AOP Proxies] for a thorough examination of exactly what this
|
||||
implementation detail actually means.
|
||||
|
||||
|
||||
|
||||
|
||||
xref:core/aop/proxying.adoc#aop-understanding-aop-proxies[Understanding AOP Proxies]
|
||||
for a thorough examination of exactly what this implementation detail actually means.
|
||||
|
|
|
|||
|
|
@ -52,10 +52,6 @@ configuration-style approach. The fact that this chapter chooses to introduce th
|
|||
@AspectJ-style approach first should not be taken as an indication that the Spring team
|
||||
favors the @AspectJ annotation-style approach over the Spring XML configuration-style.
|
||||
|
||||
See xref:core/aop/choosing.adoc[Choosing which AOP Declaration Style to Use] for a more complete discussion of the advantages and disadvantages of
|
||||
each style.
|
||||
See xref:core/aop/choosing.adoc[Choosing which AOP Declaration Style to Use] for a more
|
||||
complete discussion of the advantages and disadvantages of each style.
|
||||
====
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,3 @@ It is perfectly possible to mix @AspectJ style aspects by using the auto-proxyin
|
|||
schema-defined `<aop:aspect>` aspects, `<aop:advisor>` declared advisors, and even proxies
|
||||
and interceptors in other styles in the same configuration. All of these are implemented
|
||||
by using the same underlying support mechanism and can co-exist without any difficulty.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -61,7 +61,6 @@ proxies _for all three of them_.
|
|||
====
|
||||
|
||||
|
||||
|
||||
[[aop-understanding-aop-proxies]]
|
||||
== Understanding AOP Proxies
|
||||
|
||||
|
|
@ -291,4 +290,3 @@ Kotlin::
|
|||
|
||||
NOTE: AspectJ compile-time weaving and load-time weaving do not have this self-invocation
|
||||
issue because they apply advice within the bytecode instead of via a proxy.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,6 @@ use either only the `<aop:config>` style or only the `AutoProxyCreator` style an
|
|||
never mix them.
|
||||
|
||||
|
||||
|
||||
[[aop-schema-declaring-an-aspect]]
|
||||
== Declaring an Aspect
|
||||
|
||||
|
|
@ -54,7 +53,6 @@ The bean that backs the aspect (`aBean` in this case) can of course be configure
|
|||
dependency injected just like any other Spring bean.
|
||||
|
||||
|
||||
|
||||
[[aop-schema-pointcuts]]
|
||||
== Declaring a Pointcut
|
||||
|
||||
|
|
@ -177,9 +175,7 @@ follows:
|
|||
|
||||
Note that pointcuts defined in this way are referred to by their XML `id` and cannot be
|
||||
used as named pointcuts to form composite pointcuts. The named pointcut support in the
|
||||
schema-based definition style is thus more limited than that offered by the @AspectJ
|
||||
style.
|
||||
|
||||
schema-based definition style is thus more limited than that offered by the @AspectJ style.
|
||||
|
||||
|
||||
[[aop-schema-advice]]
|
||||
|
|
@ -188,7 +184,6 @@ style.
|
|||
The schema-based AOP support uses the same five kinds of advice as the @AspectJ style, and they have
|
||||
exactly the same semantics.
|
||||
|
||||
|
||||
[[aop-schema-advice-before]]
|
||||
=== Before Advice
|
||||
|
||||
|
|
@ -237,7 +232,6 @@ that contains the advice. Before a data access operation is performed (a method
|
|||
join point matched by the pointcut expression), the `doAccessCheck` method on the aspect
|
||||
bean is invoked.
|
||||
|
||||
|
||||
[[aop-schema-advice-after-returning]]
|
||||
=== After Returning Advice
|
||||
|
||||
|
|
@ -295,7 +289,6 @@ Kotlin::
|
|||
----
|
||||
======
|
||||
|
||||
|
||||
[[aop-schema-advice-after-throwing]]
|
||||
=== After Throwing Advice
|
||||
|
||||
|
|
@ -353,7 +346,6 @@ Kotlin::
|
|||
----
|
||||
======
|
||||
|
||||
|
||||
[[aop-schema-advice-after-finally]]
|
||||
=== After (Finally) Advice
|
||||
|
||||
|
|
@ -372,7 +364,6 @@ You can declare it by using the `after` element, as the following example shows:
|
|||
</aop:aspect>
|
||||
----
|
||||
|
||||
|
||||
[[aop-schema-advice-around]]
|
||||
=== Around Advice
|
||||
|
||||
|
|
@ -444,17 +435,18 @@ Kotlin::
|
|||
----
|
||||
======
|
||||
|
||||
|
||||
[[aop-schema-params]]
|
||||
=== Advice Parameters
|
||||
|
||||
The schema-based declaration style supports fully typed advice in the same way as
|
||||
described for the @AspectJ support -- by matching pointcut parameters by name against
|
||||
advice method parameters. See xref:core/aop/ataspectj/advice.adoc#aop-ataspectj-advice-params[Advice Parameters] for details. If you wish
|
||||
to explicitly specify argument names for the advice methods (not relying on the
|
||||
advice method parameters. See
|
||||
xref:core/aop/ataspectj/advice.adoc#aop-ataspectj-advice-params[Advice Parameters] for details.
|
||||
If you wish to explicitly specify argument names for the advice methods (not relying on the
|
||||
detection strategies previously described), you can do so by using the `arg-names`
|
||||
attribute of the advice element, which is treated in the same manner as the `argNames`
|
||||
attribute in an advice annotation (as described in xref:core/aop/ataspectj/advice.adoc#aop-ataspectj-advice-params-names[Determining Argument Names]).
|
||||
attribute in an advice annotation (as described in
|
||||
xref:core/aop/ataspectj/advice.adoc#aop-ataspectj-advice-params-names[Determining Argument Names]).
|
||||
The following example shows how to specify an argument name in XML:
|
||||
|
||||
[source,xml,indent=0,subs="verbatim"]
|
||||
|
|
@ -464,7 +456,8 @@ The following example shows how to specify an argument name in XML:
|
|||
method="audit"
|
||||
arg-names="auditable" />
|
||||
----
|
||||
<1> References the `publicMethod` named pointcut defined in xref:core/aop/ataspectj/pointcuts.adoc#aop-pointcuts-combining[Combining Pointcut Expressions].
|
||||
<1> References the `publicMethod` named pointcut defined in
|
||||
xref:core/aop/ataspectj/pointcuts.adoc#aop-pointcuts-combining[Combining Pointcut Expressions].
|
||||
|
||||
The `arg-names` attribute accepts a comma-delimited list of parameter names.
|
||||
|
||||
|
|
@ -645,15 +638,15 @@ ms % Task name
|
|||
00000 ? execution(getFoo)
|
||||
----
|
||||
|
||||
|
||||
[[aop-ordering]]
|
||||
=== Advice Ordering
|
||||
|
||||
When multiple pieces of advice need to run at the same join point (executing method)
|
||||
the ordering rules are as described in xref:core/aop/ataspectj/advice.adoc#aop-ataspectj-advice-ordering[Advice Ordering]. The precedence
|
||||
between aspects is determined via the `order` attribute in the `<aop:aspect>` element or
|
||||
by either adding the `@Order` annotation to the bean that backs the aspect or by having
|
||||
the bean implement the `Ordered` interface.
|
||||
the ordering rules are as described in
|
||||
xref:core/aop/ataspectj/advice.adoc#aop-ataspectj-advice-ordering[Advice Ordering]. The
|
||||
precedence between aspects is determined via the `order` attribute in the `<aop:aspect>`
|
||||
element or by either adding the `@Order` annotation to the bean that backs the aspect
|
||||
or by having the bean implement the `Ordered` interface.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
|
@ -676,7 +669,6 @@ at the aspect level.
|
|||
====
|
||||
|
||||
|
||||
|
||||
[[aop-schema-introductions]]
|
||||
== Introductions
|
||||
|
||||
|
|
@ -756,7 +748,6 @@ Kotlin::
|
|||
======
|
||||
|
||||
|
||||
|
||||
[[aop-schema-instantiation-models]]
|
||||
== Aspect Instantiation Models
|
||||
|
||||
|
|
@ -764,7 +755,6 @@ The only supported instantiation model for schema-defined aspects is the singlet
|
|||
model. Other instantiation models may be supported in future releases.
|
||||
|
||||
|
||||
|
||||
[[aop-schema-advisors]]
|
||||
== Advisors
|
||||
|
||||
|
|
@ -772,7 +762,8 @@ The concept of "advisors" comes from the AOP support defined in Spring
|
|||
and does not have a direct equivalent in AspectJ. An advisor is like a small
|
||||
self-contained aspect that has a single piece of advice. The advice itself is
|
||||
represented by a bean and must implement one of the advice interfaces described in
|
||||
xref:core/aop-api/advice.adoc#aop-api-advice-types[Advice Types in Spring]. Advisors can take advantage of AspectJ pointcut expressions.
|
||||
xref:core/aop-api/advice.adoc#aop-api-advice-types[Advice Types in Spring].
|
||||
Advisors can take advantage of AspectJ pointcut expressions.
|
||||
|
||||
Spring supports the advisor concept with the `<aop:advisor>` element. You most
|
||||
commonly see it used in conjunction with transactional advice, which also has its own
|
||||
|
|
@ -805,7 +796,6 @@ To define the precedence of an advisor so that the advice can participate in ord
|
|||
use the `order` attribute to define the `Ordered` value of the advisor.
|
||||
|
||||
|
||||
|
||||
[[aop-schema-example]]
|
||||
== An AOP Schema Example
|
||||
|
||||
|
|
@ -981,7 +971,3 @@ pointcut expression so that only `@Idempotent` operations match, as follows:
|
|||
expression="execution(* com.xyz.service.*.*(..)) and
|
||||
@annotation(com.xyz.service.Idempotent)"/>
|
||||
----
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,12 +8,14 @@ alone.
|
|||
|
||||
Spring ships with a small AspectJ aspect library, which is available stand-alone in your
|
||||
distribution as `spring-aspects.jar`. You need to add this to your classpath in order
|
||||
to use the aspects in it. xref:core/aop/using-aspectj.adoc#aop-atconfigurable[Using AspectJ to Dependency Inject Domain Objects with Spring] and xref:core/aop/using-aspectj.adoc#aop-ajlib-other[Other Spring aspects for AspectJ] discuss the
|
||||
content of this library and how you can use it. xref:core/aop/using-aspectj.adoc#aop-aj-configure[Configuring AspectJ Aspects by Using Spring IoC] discusses how to
|
||||
dependency inject AspectJ aspects that are woven using the AspectJ compiler. Finally,
|
||||
xref:core/aop/using-aspectj.adoc#aop-aj-ltw[Load-time Weaving with AspectJ in the Spring Framework] provides an introduction to load-time weaving for Spring applications
|
||||
that use AspectJ.
|
||||
|
||||
to use the aspects in it.
|
||||
xref:core/aop/using-aspectj.adoc#aop-atconfigurable[Using AspectJ to Dependency Inject Domain Objects with Spring]
|
||||
and xref:core/aop/using-aspectj.adoc#aop-ajlib-other[Other Spring aspects for AspectJ]
|
||||
discuss the content of this library and how you can use it.
|
||||
xref:core/aop/using-aspectj.adoc#aop-aj-configure[Configuring AspectJ Aspects by Using Spring IoC]
|
||||
discusses how to dependency inject AspectJ aspects that are woven using the AspectJ compiler. Finally,
|
||||
xref:core/aop/using-aspectj.adoc#aop-aj-ltw[Load-time Weaving with AspectJ in the Spring Framework]
|
||||
provides an introduction to load-time weaving for Spring applications that use AspectJ.
|
||||
|
||||
|
||||
[[aop-atconfigurable]]
|
||||
|
|
@ -206,7 +208,6 @@ not use `@Configurable` on bean classes that are registered as regular Spring be
|
|||
with the container. Doing so results in double initialization, once through the
|
||||
container and once through the aspect.
|
||||
|
||||
|
||||
[[aop-configurable-testing]]
|
||||
=== Unit Testing `@Configurable` Objects
|
||||
|
||||
|
|
@ -219,7 +220,6 @@ you can still unit test outside of the container as normal, but you see a warnin
|
|||
message each time that you construct a `@Configurable` object indicating that it has
|
||||
not been configured by Spring.
|
||||
|
||||
|
||||
[[aop-configurable-container]]
|
||||
=== Working with Multiple Application Contexts
|
||||
|
||||
|
|
@ -249,7 +249,6 @@ is added only to the container-wide classpath (and hence loaded by the shared pa
|
|||
not what you want).
|
||||
|
||||
|
||||
|
||||
[[aop-ajlib-other]]
|
||||
== Other Spring aspects for AspectJ
|
||||
|
||||
|
|
@ -302,7 +301,6 @@ fully qualified class names:
|
|||
----
|
||||
|
||||
|
||||
|
||||
[[aop-aj-configure]]
|
||||
== Configuring AspectJ Aspects by Using Spring IoC
|
||||
|
||||
|
|
@ -357,7 +355,6 @@ results in the creation of Spring AOP proxies. The @AspectJ style of aspect
|
|||
declaration is being used here, but the AspectJ runtime is not involved.
|
||||
|
||||
|
||||
|
||||
[[aop-aj-ltw]]
|
||||
== Load-time Weaving with AspectJ in the Spring Framework
|
||||
|
||||
|
|
@ -391,7 +388,6 @@ LTW that uses Spring, followed by detailed specifics about elements introduced i
|
|||
example. For a complete example, see the
|
||||
{petclinic-github-org}/spring-framework-petclinic[Petclinic sample application based on Spring Framework].
|
||||
|
||||
|
||||
[[aop-aj-ltw-first-example]]
|
||||
=== A First Example
|
||||
|
||||
|
|
@ -677,7 +673,6 @@ nice example of a development-time aspect that developers can use during develop
|
|||
and then easily exclude from builds of the application being deployed
|
||||
into UAT or production.
|
||||
|
||||
|
||||
[[aop-aj-ltw-the-aspects]]
|
||||
=== Aspects
|
||||
|
||||
|
|
@ -686,7 +681,6 @@ either the AspectJ language itself, or you can write your aspects in the @Aspect
|
|||
Your aspects are then both valid AspectJ and Spring AOP aspects.
|
||||
Furthermore, the compiled aspect classes need to be available on the classpath.
|
||||
|
||||
|
||||
[[aop-aj-ltw-aop_dot_xml]]
|
||||
=== `META-INF/aop.xml`
|
||||
|
||||
|
|
@ -716,7 +710,6 @@ The structure and contents of this file is detailed in the LTW part of the
|
|||
{aspectj-docs-devguide}/ltw-configuration.html[AspectJ reference
|
||||
documentation]. Because the `aop.xml` file is 100% AspectJ, we do not describe it further here.
|
||||
|
||||
|
||||
[[aop-aj-ltw-libraries]]
|
||||
=== Required libraries (JARS)
|
||||
|
||||
|
|
@ -731,7 +724,6 @@ If you use the xref:core/aop/using-aspectj.adoc#aop-aj-ltw-environments-generic[
|
|||
|
||||
* `spring-instrument.jar`
|
||||
|
||||
|
||||
[[aop-aj-ltw-spring]]
|
||||
=== Spring Configuration
|
||||
|
||||
|
|
@ -831,7 +823,6 @@ possible values:
|
|||
then AspectJ weaving is on. Otherwise, it is off. This is the default value.
|
||||
|===
|
||||
|
||||
|
||||
[[aop-aj-ltw-environments]]
|
||||
=== Environment-specific Configuration
|
||||
|
||||
|
|
@ -880,7 +871,3 @@ Note that this requires modification of the JVM launch script, which may prevent
|
|||
from using this in application server environments (depending on your server and your
|
||||
operation policies). That said, for one-app-per-JVM deployments such as standalone
|
||||
Spring Boot applications, you typically control the entire JVM setup in any case.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -5,6 +5,7 @@ This chapter covers Spring's Ahead of Time (AOT) optimizations.
|
|||
|
||||
For AOT support specific to integration tests, see xref:testing/testcontext-framework/aot.adoc[Ahead of Time Support for Tests].
|
||||
|
||||
|
||||
[[aot.introduction]]
|
||||
== Introduction to Ahead of Time Optimizations
|
||||
|
||||
|
|
@ -35,6 +36,7 @@ A Spring AOT processed application typically generates:
|
|||
NOTE: At the moment, AOT is focused on allowing Spring applications to be deployed as native images using GraalVM.
|
||||
We intend to support more JVM-based use cases in future generations.
|
||||
|
||||
|
||||
[[aot.basics]]
|
||||
== AOT Engine Overview
|
||||
|
||||
|
|
@ -51,6 +53,7 @@ The `RuntimeHints` instance can also be used to generate the relevant GraalVM na
|
|||
|
||||
Those steps are covered in greater detail in the sections below.
|
||||
|
||||
|
||||
[[aot.refresh]]
|
||||
== Refresh for AOT Processing
|
||||
|
||||
|
|
@ -88,6 +91,7 @@ This makes sure to create any proxy that will be required at runtime.
|
|||
|
||||
Once this part completes, the `BeanFactory` contains the bean definitions that are necessary for the application to run. It does not trigger bean instantiation but allows the AOT engine to inspect the beans that will be created at runtime.
|
||||
|
||||
|
||||
[[aot.bean-factory-initialization-contributions]]
|
||||
== Bean Factory Initialization AOT Contributions
|
||||
|
||||
|
|
@ -110,7 +114,6 @@ We generally recommend that this interface is only implemented by infrastructure
|
|||
If such a bean is registered using an `@Bean` factory method, ensure the method is `static` so that its enclosing `@Configuration` class does not have to be initialized.
|
||||
====
|
||||
|
||||
|
||||
[[aot.bean-registration-contributions]]
|
||||
=== Bean Registration AOT Contributions
|
||||
|
||||
|
|
@ -224,6 +227,7 @@ There is a bean definition for `dataSourceConfiguration` and one for `dataSource
|
|||
When a `datasource` instance is required, a `BeanInstanceSupplier` is called.
|
||||
This supplier invokes the `dataSource()` method on the `dataSourceConfiguration` bean.
|
||||
|
||||
|
||||
[[aot.running]]
|
||||
== Running with AOT Optimizations
|
||||
|
||||
|
|
@ -235,6 +239,7 @@ NOTE: When AOT optimizations are included, some decisions that have been made at
|
|||
are hard coded in the application setup. For instance, profiles that have been enabled at
|
||||
build time are automatically enabled at runtime as well.
|
||||
|
||||
|
||||
[[aot.bestpractices]]
|
||||
== Best Practices
|
||||
|
||||
|
|
@ -564,6 +569,7 @@ Kotlin::
|
|||
----
|
||||
======
|
||||
|
||||
|
||||
[[aot.hints]]
|
||||
== Runtime Hints
|
||||
|
||||
|
|
@ -598,7 +604,6 @@ For instance, the return type of a `@Controller` method is inspected, and releva
|
|||
For cases that the core container cannot infer, you can register such hints programmatically.
|
||||
A number of convenient annotations are also provided for common use cases.
|
||||
|
||||
|
||||
[[aot.hints.import-runtime-hints]]
|
||||
=== `@ImportRuntimeHints`
|
||||
|
||||
|
|
@ -616,7 +621,6 @@ This way, if the component is not contributed to the `BeanFactory`, the hints wi
|
|||
|
||||
It is also possible to register an implementation statically by adding an entry in `META-INF/spring/aot.factories` with a key equal to the fully-qualified name of the `RuntimeHintsRegistrar` interface.
|
||||
|
||||
|
||||
[[aot.hints.reflective]]
|
||||
=== `@Reflective`
|
||||
|
||||
|
|
@ -639,7 +643,6 @@ This can be tuned by specifying a custom `ReflectiveProcessor` implementation vi
|
|||
Library authors can reuse this annotation for their own purposes.
|
||||
An example of such customization is covered in the next section.
|
||||
|
||||
|
||||
[[aot.hints.register-reflection]]
|
||||
=== `@RegisterReflection`
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,3 @@
|
|||
[[appendix]]
|
||||
= Appendix
|
||||
:page-section-summary-toc: 1
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,6 @@ Spring's extensible XML configuration mechanism is based on XML Schema. If you a
|
|||
familiar with Spring's current XML configuration extensions that come with the standard
|
||||
Spring distribution, you should first read the previous section on xref:core/appendix/xsd-schemas.adoc[XML Schemas].
|
||||
|
||||
|
||||
To create new XML configuration extensions:
|
||||
|
||||
. xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-schema[Author] an XML schema to describe your custom element(s).
|
||||
|
|
@ -38,7 +37,6 @@ examples follow later in this appendix. The intent of this first simple example
|
|||
through the basic steps of making a custom extension.)
|
||||
|
||||
|
||||
|
||||
[[xsd-custom-schema]]
|
||||
== Authoring the Schema
|
||||
|
||||
|
|
@ -110,7 +108,6 @@ can use autocompletion to let a user choose between several configuration option
|
|||
defined in the enumeration.
|
||||
|
||||
|
||||
|
||||
[[xsd-custom-namespacehandler]]
|
||||
== Coding a `NamespaceHandler`
|
||||
|
||||
|
|
@ -187,7 +184,6 @@ means that each `BeanDefinitionParser` contains only the logic for parsing a sin
|
|||
custom element, as we can see in the next step.
|
||||
|
||||
|
||||
|
||||
[[xsd-custom-parser]]
|
||||
== Using `BeanDefinitionParser`
|
||||
|
||||
|
|
@ -276,13 +272,11 @@ the basic grunt work of creating a single `BeanDefinition`.
|
|||
single `BeanDefinition` represents.
|
||||
======
|
||||
|
||||
|
||||
In this simple case, this is all that we need to do. The creation of our single
|
||||
`BeanDefinition` is handled by the `AbstractSingleBeanDefinitionParser` superclass, as
|
||||
is the extraction and setting of the bean definition's unique identifier.
|
||||
|
||||
|
||||
|
||||
[[xsd-custom-registration]]
|
||||
== Registering the Handler and the Schema
|
||||
|
||||
|
|
@ -294,7 +288,6 @@ can, for example, be distributed alongside your binary classes in a JAR file. Th
|
|||
XML parsing infrastructure automatically picks up your new extension by consuming
|
||||
these special properties files, the formats of which are detailed in the next two sections.
|
||||
|
||||
|
||||
[[xsd-custom-registration-spring-handlers]]
|
||||
=== Writing `META-INF/spring.handlers`
|
||||
|
||||
|
|
@ -313,7 +306,6 @@ The first part (the key) of the key-value pair is the URI associated with your c
|
|||
namespace extension and needs to exactly match exactly the value of the `targetNamespace`
|
||||
attribute, as specified in your custom XSD schema.
|
||||
|
||||
|
||||
[[xsd-custom-registration-spring-schemas]]
|
||||
=== Writing 'META-INF/spring.schemas'
|
||||
|
||||
|
|
@ -337,7 +329,6 @@ You are encouraged to deploy your XSD file (or files) right alongside
|
|||
the `NamespaceHandler` and `BeanDefinitionParser` classes on the classpath.
|
||||
|
||||
|
||||
|
||||
[[xsd-custom-using]]
|
||||
== Using a Custom Extension in Your Spring XML Configuration
|
||||
|
||||
|
|
@ -371,13 +362,11 @@ in a Spring XML configuration file:
|
|||
<1> Our custom bean.
|
||||
|
||||
|
||||
|
||||
[[xsd-custom-meat]]
|
||||
== More Detailed Examples
|
||||
|
||||
This section presents some more detailed examples of custom XML extensions.
|
||||
|
||||
|
||||
[[xsd-custom-custom-nested]]
|
||||
=== Nesting Custom Elements within Custom Elements
|
||||
|
||||
|
|
@ -753,7 +742,6 @@ http\://www.foo.example/schema/component=com.foo.ComponentNamespaceHandler
|
|||
http\://www.foo.example/schema/component/component.xsd=com/foo/component.xsd
|
||||
----
|
||||
|
||||
|
||||
[[xsd-custom-custom-just-attributes]]
|
||||
=== Custom Attributes on "`Normal`" Elements
|
||||
|
||||
|
|
@ -1007,5 +995,3 @@ http\://www.foo.example/schema/jcache=com.foo.JCacheNamespaceHandler
|
|||
# in 'META-INF/spring.schemas'
|
||||
http\://www.foo.example/schema/jcache/jcache.xsd=com/foo/jcache.xsd
|
||||
----
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@
|
|||
This part of the appendix lists XML schemas related to the core container.
|
||||
|
||||
|
||||
|
||||
[[xsd-schemas-util]]
|
||||
== The `util` Schema
|
||||
|
||||
|
|
@ -29,7 +28,6 @@ correct schema so that the tags in the `util` namespace are available to you):
|
|||
</beans>
|
||||
----
|
||||
|
||||
|
||||
[[xsd-schemas-util-constant]]
|
||||
=== Using `<util:constant/>`
|
||||
|
||||
|
|
@ -186,7 +184,6 @@ Kotlin::
|
|||
</bean>
|
||||
----
|
||||
|
||||
|
||||
[[xsd-schemas-util-property-path]]
|
||||
=== Using `<util:property-path/>`
|
||||
|
||||
|
|
@ -308,7 +305,6 @@ You can specifically set the result type in the actual definition. This is not n
|
|||
for most use cases, but it can sometimes be useful. See the javadoc for more info on
|
||||
this feature.
|
||||
|
||||
|
||||
[[xsd-schemas-util-properties]]
|
||||
=== Using `<util:properties/>`
|
||||
|
||||
|
|
@ -334,7 +330,6 @@ The following example uses a `util:properties` element to make a more concise re
|
|||
<util:properties id="jdbcConfiguration" location="classpath:com/foo/jdbc-production.properties"/>
|
||||
----
|
||||
|
||||
|
||||
[[xsd-schemas-util-list]]
|
||||
=== Using `<util:list/>`
|
||||
|
||||
|
|
@ -389,7 +384,6 @@ following configuration:
|
|||
|
||||
If no `list-class` attribute is supplied, the container chooses a `List` implementation.
|
||||
|
||||
|
||||
[[xsd-schemas-util-map]]
|
||||
=== Using `<util:map/>`
|
||||
|
||||
|
|
@ -444,7 +438,6 @@ following configuration:
|
|||
|
||||
If no `'map-class'` attribute is supplied, the container chooses a `Map` implementation.
|
||||
|
||||
|
||||
[[xsd-schemas-util-set]]
|
||||
=== Using `<util:set/>`
|
||||
|
||||
|
|
@ -500,7 +493,6 @@ following configuration:
|
|||
If no `set-class` attribute is supplied, the container chooses a `Set` implementation.
|
||||
|
||||
|
||||
|
||||
[[xsd-schemas-aop]]
|
||||
== The `aop` Schema
|
||||
|
||||
|
|
@ -530,7 +522,6 @@ are available to you):
|
|||
----
|
||||
|
||||
|
||||
|
||||
[[xsd-schemas-context]]
|
||||
== The `context` Schema
|
||||
|
||||
|
|
@ -555,7 +546,6 @@ available to you:
|
|||
</beans>
|
||||
----
|
||||
|
||||
|
||||
[[xsd-schemas-context-pphc]]
|
||||
=== Using `<property-placeholder/>`
|
||||
|
||||
|
|
@ -599,34 +589,25 @@ element for that purpose. Similarly, Spring's
|
|||
xref:integration/cache/annotations.adoc[caching annotations] need to be explicitly
|
||||
xref:integration/cache/annotations.adoc#cache-annotation-enable[enabled] as well.
|
||||
|
||||
|
||||
[[xsd-schemas-context-component-scan]]
|
||||
=== Using `<component-scan/>`
|
||||
|
||||
This element is detailed in the section on xref:core/beans/annotation-config.adoc[annotation-based container configuration]
|
||||
.
|
||||
|
||||
This element is detailed in the section on xref:core/beans/annotation-config.adoc[annotation-based container configuration].
|
||||
|
||||
[[xsd-schemas-context-ltw]]
|
||||
=== Using `<load-time-weaver/>`
|
||||
|
||||
This element is detailed in the section on xref:core/aop/using-aspectj.adoc#aop-aj-ltw[load-time weaving with AspectJ in the Spring Framework]
|
||||
.
|
||||
|
||||
This element is detailed in the section on xref:core/aop/using-aspectj.adoc#aop-aj-ltw[load-time weaving with AspectJ in the Spring Framework].
|
||||
|
||||
[[xsd-schemas-context-sc]]
|
||||
=== Using `<spring-configured/>`
|
||||
|
||||
This element is detailed in the section on xref:core/aop/using-aspectj.adoc#aop-atconfigurable[using AspectJ to dependency inject domain objects with Spring]
|
||||
.
|
||||
|
||||
This element is detailed in the section on xref:core/aop/using-aspectj.adoc#aop-atconfigurable[using AspectJ to dependency inject domain objects with Spring].
|
||||
|
||||
[[xsd-schemas-context-mbe]]
|
||||
=== Using `<mbean-export/>`
|
||||
|
||||
This element is detailed in the section on xref:integration/jmx/naming.adoc#jmx-context-mbeanexport[configuring annotation-based MBean export]
|
||||
.
|
||||
|
||||
This element is detailed in the section on xref:integration/jmx/naming.adoc#jmx-context-mbeanexport[configuring annotation-based MBean export].
|
||||
|
||||
|
||||
[[xsd-schemas-beans]]
|
||||
|
|
@ -666,7 +647,3 @@ as it stands).
|
|||
|
||||
In the case of the preceding example, you could assume that there is some logic that consumes
|
||||
the bean definition and sets up some caching infrastructure that uses the supplied metadata.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,3 @@
|
|||
:page-section-summary-toc: 1
|
||||
|
||||
This chapter covers Spring's Inversion of Control (IoC) container.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -62,6 +62,3 @@ application context in which it is defined. This means that, if you put
|
|||
it only checks for `@Autowired` beans in your controllers, and not your services. See
|
||||
xref:web/webmvc/mvc-servlet.adoc[The DispatcherServlet] for more information.
|
||||
====
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -152,6 +152,3 @@ The corresponding bean definitions follow:
|
|||
|
||||
</beans>
|
||||
----
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -568,6 +568,3 @@ the following example:
|
|||
</beans>
|
||||
----
|
||||
--
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -530,6 +530,3 @@ The `@Autowired`, `@Inject`, `@Value`, and `@Resource` annotations are handled b
|
|||
within your own `BeanPostProcessor` or `BeanFactoryPostProcessor` types (if any).
|
||||
These types must be 'wired up' explicitly by using XML or a Spring `@Bean` method.
|
||||
====
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -28,6 +28,3 @@ with the `CustomAutowireConfigurer`
|
|||
When multiple beans qualify as autowire candidates, the determination of a "`primary`" is
|
||||
as follows: If exactly one bean definition among the candidates has a `primary`
|
||||
attribute set to `true`, it is selected.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -96,6 +96,3 @@ Kotlin::
|
|||
private lateinit var s: List<Store<Integer>>
|
||||
----
|
||||
======
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -64,7 +64,3 @@ JDK 11. As of Jakarta EE 9, the package lives in `jakarta.annotation` now. If ne
|
|||
the `jakarta.annotation-api` artifact needs to be obtained via Maven Central now,
|
||||
simply to be added to the application's classpath like any other library.
|
||||
====
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -142,4 +142,3 @@ Kotlin::
|
|||
`ApplicationContext`.
|
||||
======
|
||||
--
|
||||
|
||||
|
|
|
|||
|
|
@ -241,5 +241,3 @@ Kotlin::
|
|||
@Value("#{{'Thriller': 100, 'Comedy': 300}}") private val countOfMoviesPerCatalog: Map<String, Int>)
|
||||
----
|
||||
======
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,6 @@ created and initialized, you have a fully configured and executable system or ap
|
|||
image::container-magic.png[]
|
||||
|
||||
|
||||
|
||||
[[beans-factory-metadata]]
|
||||
== Configuration Metadata
|
||||
|
||||
|
|
@ -63,8 +62,6 @@ Typically, one does not configure fine-grained domain objects in the container,
|
|||
it is usually the responsibility of repositories and business logic to create and load
|
||||
domain objects.
|
||||
|
||||
|
||||
|
||||
[[beans-factory-xml]]
|
||||
=== XML as an External Configuration DSL
|
||||
|
||||
|
|
@ -188,7 +185,6 @@ definition. This linkage between `id` and `ref` elements expresses the dependenc
|
|||
collaborating objects. For details of configuring an object's dependencies, see
|
||||
xref:core/beans/dependencies.adoc[Dependencies].
|
||||
|
||||
|
||||
[[beans-factory-xml-import]]
|
||||
=== Composing XML-based Configuration Metadata
|
||||
|
||||
|
|
@ -243,7 +239,6 @@ The namespace itself provides the import directive feature. Further
|
|||
configuration features beyond plain bean definitions are available in a selection
|
||||
of XML namespaces provided by Spring -- for example, the `context` and `util` namespaces.
|
||||
|
||||
|
||||
[[beans-factory-groovy]]
|
||||
=== The Groovy Bean Definition DSL
|
||||
|
||||
|
|
@ -278,7 +273,6 @@ supports Spring's XML configuration namespaces. It also allows for importing XML
|
|||
bean definition files through an `importBeans` directive.
|
||||
|
||||
|
||||
|
||||
[[beans-factory-client]]
|
||||
== Using the Container
|
||||
|
||||
|
|
@ -402,6 +396,3 @@ code should never use them. Indeed, your application code should have no calls t
|
|||
Spring's integration with web frameworks provides dependency injection for various web
|
||||
framework components such as controllers and JSF-managed beans, letting you declare
|
||||
a dependency on a specific bean through metadata (such as an autowiring annotation).
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,6 @@ operate on shared `BeanDefinition` objects as a core metadata representation.
|
|||
This is the essence of what makes Spring's container so flexible and extensible.
|
||||
|
||||
|
||||
|
||||
[[context-introduction-ctx-vs-beanfactory]]
|
||||
== `BeanFactory` or `ApplicationContext`?
|
||||
|
||||
|
|
|
|||
|
|
@ -78,7 +78,3 @@ important (at least for singleton beans) that if you have a (parent) bean defini
|
|||
which you intend to use only as a template, and this definition specifies a class, you
|
||||
must make sure to set the __abstract__ attribute to __true__, otherwise the application
|
||||
context will actually (attempt to) pre-instantiate the `abstract` bean.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,6 @@ use these features.
|
|||
====
|
||||
|
||||
|
||||
|
||||
[[beans-stereotype-annotations]]
|
||||
== `@Component` and Further Stereotype Annotations
|
||||
|
||||
|
|
@ -46,7 +45,6 @@ clearly the better choice. Similarly, as stated earlier, `@Repository` is alread
|
|||
supported as a marker for automatic exception translation in your persistence layer.
|
||||
|
||||
|
||||
|
||||
[[beans-meta-annotations]]
|
||||
== Using Meta-annotations and Composed Annotations
|
||||
|
||||
|
|
@ -195,7 +193,6 @@ For further details, see the
|
|||
wiki page.
|
||||
|
||||
|
||||
|
||||
[[beans-scanning-autodetection]]
|
||||
== Automatically Detecting Classes and Registering Bean Definitions
|
||||
|
||||
|
|
@ -334,7 +331,6 @@ NOTE: You can disable the registration of `AutowiredAnnotationBeanPostProcessor`
|
|||
with a value of `false`.
|
||||
|
||||
|
||||
|
||||
[[beans-scanning-filters]]
|
||||
== Using Filters to Customize Scanning
|
||||
|
||||
|
|
@ -426,7 +422,6 @@ annotated or meta-annotated with `@Component`, `@Repository`, `@Service`, `@Cont
|
|||
`@RestController`, or `@Configuration`.
|
||||
|
||||
|
||||
|
||||
[[beans-factorybeans-annotations]]
|
||||
== Defining Bean Metadata within Components
|
||||
|
||||
|
|
@ -663,7 +658,6 @@ analogous to how the container selects between multiple `@Autowired` constructor
|
|||
====
|
||||
|
||||
|
||||
|
||||
[[beans-scanning-name-generator]]
|
||||
== Naming Autodetected Components
|
||||
|
||||
|
|
@ -795,7 +789,6 @@ components may be making explicit references to it. On the other hand, the
|
|||
auto-generated names are adequate whenever the container is responsible for wiring.
|
||||
|
||||
|
||||
|
||||
[[beans-scanning-scope-resolver]]
|
||||
== Providing a Scope for Autodetected Components
|
||||
|
||||
|
|
@ -918,7 +911,6 @@ Kotlin::
|
|||
----
|
||||
|
||||
|
||||
|
||||
[[beans-scanning-qualifiers]]
|
||||
== Providing Qualifier Metadata with Annotations
|
||||
|
||||
|
|
@ -1010,7 +1002,3 @@ NOTE: As with most annotation-based alternatives, keep in mind that the annotati
|
|||
bound to the class definition itself, while the use of XML allows for multiple beans
|
||||
of the same type to provide variations in their qualifier metadata, because that
|
||||
metadata is provided per-instance rather than per-class.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,6 @@ package also provides the following functionality:
|
|||
`HierarchicalBeanFactory` interface.
|
||||
|
||||
|
||||
|
||||
[[context-functionality-messagesource]]
|
||||
== Internationalization using `MessageSource`
|
||||
|
||||
|
|
@ -273,7 +272,6 @@ See the {spring-framework-api}/context/support/ReloadableResourceBundleMessageSo
|
|||
javadoc for details.
|
||||
|
||||
|
||||
|
||||
[[context-functionality-events]]
|
||||
== Standard and Custom Events
|
||||
|
||||
|
|
@ -534,7 +532,6 @@ complete support for building lightweight,
|
|||
https://www.enterpriseintegrationpatterns.com[pattern-oriented], event-driven
|
||||
architectures that build upon the well-known Spring programming model.
|
||||
|
||||
|
||||
[[context-functionality-events-annotation]]
|
||||
=== Annotation-based Event Listeners
|
||||
|
||||
|
|
@ -707,7 +704,6 @@ The `handleBlockedListEvent()` method publishes a new `ListUpdateEvent` for ever
|
|||
`BlockedListEvent` that it handles. If you need to publish several events, you can return
|
||||
a `Collection` or an array of events instead.
|
||||
|
||||
|
||||
[[context-functionality-events-async]]
|
||||
=== Asynchronous Listeners
|
||||
|
||||
|
|
@ -754,7 +750,6 @@ Be aware of the following limitations when using asynchronous events:
|
|||
See xref:integration/observability.adoc#observability.application-events[the `@EventListener` Observability section]
|
||||
for more information on Observability concerns.
|
||||
|
||||
|
||||
[[context-functionality-events-order]]
|
||||
=== Ordering Listeners
|
||||
|
||||
|
|
@ -786,7 +781,6 @@ Kotlin::
|
|||
----
|
||||
======
|
||||
|
||||
|
||||
[[context-functionality-events-generics]]
|
||||
=== Generic Events
|
||||
|
||||
|
|
@ -880,7 +874,6 @@ for example, for processing all events asynchronously and/or for handling listen
|
|||
----
|
||||
|
||||
|
||||
|
||||
[[context-functionality-resources]]
|
||||
== Convenient Access to Low-level Resources
|
||||
|
||||
|
|
@ -913,7 +906,6 @@ with special prefixes to force loading of definitions from the classpath or a UR
|
|||
regardless of the actual context type.
|
||||
|
||||
|
||||
|
||||
[[context-functionality-startup]]
|
||||
== Application Startup Tracking
|
||||
|
||||
|
|
@ -990,6 +982,7 @@ or ask for the `ApplicationStartup` type on any injection point.
|
|||
NOTE: Developers should not use the `"spring.*"` namespace when creating custom startup steps.
|
||||
This namespace is reserved for internal Spring usage and is subject to change.
|
||||
|
||||
|
||||
[[context-create]]
|
||||
== Convenient ApplicationContext Instantiation for Web Applications
|
||||
|
||||
|
|
@ -1022,7 +1015,6 @@ Examples are `/WEB-INF/{asterisk}Context.xml` (for all files with names that end
|
|||
(for all such files in any subdirectory of `WEB-INF`).
|
||||
|
||||
|
||||
|
||||
[[context-deploy-rar]]
|
||||
== Deploying a Spring `ApplicationContext` as a Jakarta EE RAR File
|
||||
|
||||
|
|
@ -1053,7 +1045,8 @@ all application classes into a RAR file (which is a standard JAR file with a dif
|
|||
file extension).
|
||||
. Add all required library JARs into the root of the RAR archive.
|
||||
. Add a
|
||||
`META-INF/ra.xml` deployment descriptor (as shown in the {spring-framework-api}/jca/context/SpringContextResourceAdapter.html[javadoc for `SpringContextResourceAdapter`])
|
||||
`META-INF/ra.xml` deployment descriptor (as shown in the
|
||||
{spring-framework-api}/jca/context/SpringContextResourceAdapter.html[javadoc for `SpringContextResourceAdapter`])
|
||||
and the corresponding Spring XML bean definition file(s) (typically
|
||||
`META-INF/applicationContext.xml`).
|
||||
. Drop the resulting RAR file into your
|
||||
|
|
@ -1066,7 +1059,3 @@ other modules. A RAR-based `ApplicationContext` may also, for example, schedule
|
|||
or react to new files in the file system (or the like). If it needs to allow synchronous
|
||||
access from the outside, it could (for example) export RMI endpoints, which may be used
|
||||
by other application modules on the same machine.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -45,8 +45,5 @@ xref:data-access/orm/jpa.adoc[Spring's JPA support] where load-time weaving may
|
|||
necessary for JPA class transformation.
|
||||
Consult the
|
||||
{spring-framework-api}/orm/jpa/LocalContainerEntityManagerFactoryBean.html[`LocalContainerEntityManagerFactoryBean`]
|
||||
javadoc for more detail. For more on AspectJ load-time weaving, see xref:core/aop/using-aspectj.adoc#aop-aj-ltw[Load-time Weaving with AspectJ in the Spring Framework].
|
||||
|
||||
|
||||
|
||||
|
||||
javadoc for more detail. For more on AspectJ load-time weaving, see
|
||||
xref:core/aop/using-aspectj.adoc#aop-aj-ltw[Load-time Weaving with AspectJ in the Spring Framework].
|
||||
|
|
|
|||
|
|
@ -74,7 +74,6 @@ lead to concurrent access exceptions, inconsistent state in the bean container,
|
|||
====
|
||||
|
||||
|
||||
|
||||
[[beans-definition-overriding]]
|
||||
== Overriding Beans
|
||||
|
||||
|
|
@ -104,7 +103,6 @@ explicit support for this as of Spring Framework 6.2. Please refer to
|
|||
xref:testing/testcontext-framework/bean-overriding.adoc[this section] for more details.
|
||||
|
||||
|
||||
|
||||
[[beans-beanname]]
|
||||
== Naming Beans
|
||||
|
||||
|
|
@ -147,7 +145,6 @@ case when there is more than one character and both the first and second charact
|
|||
are upper case, the original casing gets preserved. These are the same rules as
|
||||
defined by `java.beans.Introspector.decapitalize` (which Spring uses here).
|
||||
|
||||
|
||||
[[beans-beanname-alias]]
|
||||
=== Aliasing a Bean outside the Bean Definition
|
||||
|
||||
|
|
@ -197,7 +194,6 @@ See xref:core/beans/java/bean-annotation.adoc[Using the `@Bean` Annotation] for
|
|||
****
|
||||
|
||||
|
||||
|
||||
[[beans-factory-class]]
|
||||
== Instantiating Beans
|
||||
|
||||
|
|
@ -209,7 +205,8 @@ If you use XML-based configuration metadata, you specify the type (or class) of
|
|||
that is to be instantiated in the `class` attribute of the `<bean/>` element. This
|
||||
`class` attribute (which, internally, is a `Class` property on a `BeanDefinition`
|
||||
instance) is usually mandatory. (For exceptions, see
|
||||
xref:core/beans/definition.adoc#beans-factory-class-instance-factory-method[Instantiation by Using an Instance Factory Method] and xref:core/beans/child-bean-definitions.adoc[Bean Definition Inheritance].)
|
||||
xref:core/beans/definition.adoc#beans-factory-class-instance-factory-method[Instantiation by Using an Instance Factory Method]
|
||||
and xref:core/beans/child-bean-definitions.adoc[Bean Definition Inheritance].)
|
||||
You can use the `Class` property in one of two ways:
|
||||
|
||||
* Typically, to specify the bean class to be constructed in the case where the container
|
||||
|
|
@ -233,7 +230,6 @@ a bean definition would be `com.example.SomeThing$OtherThing` or
|
|||
`com.example.SomeThing.OtherThing`.
|
||||
****
|
||||
|
||||
|
||||
[[beans-factory-class-ctor]]
|
||||
=== Instantiation with a Constructor
|
||||
|
||||
|
|
@ -268,7 +264,6 @@ NOTE: In the case of constructor arguments, the container can select a correspon
|
|||
constructor among several overloaded constructors. That said, to avoid ambiguities,
|
||||
it is recommended to keep your constructor signatures as straightforward as possible.
|
||||
|
||||
|
||||
[[beans-factory-class-static-factory-method]]
|
||||
=== Instantiation with a Static Factory Method
|
||||
|
||||
|
|
@ -346,7 +341,6 @@ overloads of the `mock` method. Choose the most specific variant of `mock` possi
|
|||
----
|
||||
====
|
||||
|
||||
|
||||
[[beans-factory-class-instance-factory-method]]
|
||||
=== Instantiation by Using an Instance Factory Method
|
||||
|
||||
|
|
@ -478,7 +472,6 @@ xref:core/beans/definition.adoc#beans-factory-class-static-factory-method[static
|
|||
`FactoryBean` (notice the capitalization) refers to a Spring-specific
|
||||
xref:core/beans/factory-extension.adoc#beans-factory-extension-factorybean[`FactoryBean`] implementation class.
|
||||
|
||||
|
||||
[[beans-factory-type-determination]]
|
||||
=== Determining a Bean's Runtime Type
|
||||
|
||||
|
|
@ -494,5 +487,3 @@ The recommended way to find out about the actual runtime type of a particular be
|
|||
a `BeanFactory.getType` call for the specified bean name. This takes all of the above
|
||||
cases into account and returns the type of object that a `BeanFactory.getBean` call is
|
||||
going to return for the same bean name.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -7,6 +7,3 @@ Spring parlance). Even the simplest application has a few objects that work toge
|
|||
present what the end-user sees as a coherent application. This next section explains how
|
||||
you go from defining a number of bean definitions that stand alone to a fully realized
|
||||
application where objects collaborate to achieve a goal.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,8 @@ advantages:
|
|||
during development, without negating the option of switching to explicit wiring when
|
||||
the code base becomes more stable.
|
||||
|
||||
When using XML-based configuration metadata (see xref:core/beans/dependencies/factory-collaborators.adoc[Dependency Injection]), you
|
||||
When using XML-based configuration metadata (see
|
||||
xref:core/beans/dependencies/factory-collaborators.adoc[Dependency Injection]), you
|
||||
can specify the autowire mode for a bean definition with the `autowire` attribute of the
|
||||
`<bean/>` element. The autowiring functionality has four modes. You specify autowiring
|
||||
per bean and can thus choose which ones to autowire. The following table describes the
|
||||
|
|
@ -60,7 +61,6 @@ instance's values consist of all bean instances that match the expected type, an
|
|||
`Map` instance's keys contain the corresponding bean names.
|
||||
|
||||
|
||||
|
||||
[[beans-autowired-exceptions]]
|
||||
== Limitations and Disadvantages of Autowiring
|
||||
|
||||
|
|
@ -90,14 +90,14 @@ In the latter scenario, you have several options:
|
|||
|
||||
* Abandon autowiring in favor of explicit wiring.
|
||||
* Avoid autowiring for a bean definition by setting its `autowire-candidate` attributes
|
||||
to `false`, as described in the xref:core/beans/dependencies/factory-autowire.adoc#beans-factory-autowire-candidate[next section].
|
||||
to `false`, as described in the
|
||||
xref:core/beans/dependencies/factory-autowire.adoc#beans-factory-autowire-candidate[next section].
|
||||
* Designate a single bean definition as the primary candidate by setting the
|
||||
`primary` attribute of its `<bean/>` element to `true`.
|
||||
* Implement the more fine-grained control available with annotation-based configuration,
|
||||
as described in xref:core/beans/annotation-config.adoc[Annotation-based Container Configuration].
|
||||
|
||||
|
||||
|
||||
[[beans-factory-autowire-candidate]]
|
||||
== Excluding a Bean from Autowiring
|
||||
|
||||
|
|
@ -139,6 +139,3 @@ get injected by plain declared type only, rather by type plus specific qualifier
|
|||
In contrast, `autowireCandidate=false` behaves exactly like the `autowire-candidate`
|
||||
attribute as explained above: Such a bean will never get injected by type at all.
|
||||
====
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -16,8 +16,9 @@ not know the location or class of the dependencies. As a result, your classes be
|
|||
to test, particularly when the dependencies are on interfaces or abstract base classes,
|
||||
which allow for stub or mock implementations to be used in unit tests.
|
||||
|
||||
DI exists in two major variants: xref:core/beans/dependencies/factory-collaborators.adoc#beans-constructor-injection[Constructor-based dependency injection]
|
||||
and xref:core/beans/dependencies/factory-collaborators.adoc#beans-setter-injection[Setter-based dependency injection].
|
||||
DI exists in two major variants:
|
||||
xref:core/beans/dependencies/factory-collaborators.adoc#beans-constructor-injection[Constructor-based dependency injection]
|
||||
and xref:core/beans/dependencies/factory-collaborators.adoc#beans-setter-injection[Setter-based dependency injection].
|
||||
|
||||
|
||||
[[beans-constructor-injection]]
|
||||
|
|
@ -606,6 +607,3 @@ contains the `static` factory method (although, in this example, it is). An inst
|
|||
(non-static) factory method can be used in an essentially identical fashion (aside
|
||||
from the use of the `factory-bean` attribute instead of the `class` attribute), so we
|
||||
do not discuss those details here.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -37,6 +37,3 @@ in the case of xref:core/beans/factory-scopes.adoc#beans-factory-scopes-singleto
|
|||
beans only, a corresponding destruction-time dependency. Dependent beans that define a
|
||||
`depends-on` relationship with a given bean are destroyed first, prior to the given bean
|
||||
itself being destroyed. Thus, `depends-on` can also control shutdown order.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -29,6 +29,3 @@ annotated class or in XML using the `default-lazy-init` attribute on the `<beans
|
|||
shows:
|
||||
|
||||
include-code::./LazyConfiguration[tag=snippet,indent=0]
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -2,16 +2,17 @@
|
|||
= Method Injection
|
||||
|
||||
In most application scenarios, most beans in the container are
|
||||
xref:core/beans/factory-scopes.adoc#beans-factory-scopes-singleton[singletons]. When a singleton bean needs to
|
||||
collaborate with another singleton bean or a non-singleton bean needs to collaborate
|
||||
with another non-singleton bean, you typically handle the dependency by defining one
|
||||
bean as a property of the other. A problem arises when the bean lifecycles are
|
||||
different. Suppose singleton bean A needs to use non-singleton (prototype) bean B,
|
||||
xref:core/beans/factory-scopes.adoc#beans-factory-scopes-singleton[singletons]. When a
|
||||
singleton bean needs to collaborate with another singleton bean or a non-singleton bean
|
||||
needs to collaborate with another non-singleton bean, you typically handle the dependency
|
||||
by defining one bean as a property of the other. A problem arises when the bean lifecycles
|
||||
are different. Suppose singleton bean A needs to use non-singleton (prototype) bean B,
|
||||
perhaps on each method invocation on A. The container creates the singleton bean A only
|
||||
once, and thus only gets one opportunity to set the properties. The container cannot
|
||||
provide bean A with a new instance of bean B every time one is needed.
|
||||
|
||||
A solution is to forego some inversion of control. You can xref:core/beans/factory-nature.adoc#beans-factory-aware[make bean A aware of the container]
|
||||
A solution is to forego some inversion of control. You can
|
||||
xref:core/beans/factory-nature.adoc#beans-factory-aware[make bean A aware of the container]
|
||||
by implementing the `ApplicationContextAware` interface,
|
||||
and by xref:core/beans/basics.adoc#beans-factory-client[making a `getBean("B")` call to the container] ask for (a
|
||||
typically new) bean B instance every time bean A needs it. The following example
|
||||
|
|
@ -103,7 +104,6 @@ You can read more about the motivation for Method Injection in
|
|||
****
|
||||
|
||||
|
||||
|
||||
[[beans-factory-lookup-method-injection]]
|
||||
== Lookup Method Injection
|
||||
|
||||
|
|
@ -294,14 +294,14 @@ Kotlin::
|
|||
[TIP]
|
||||
====
|
||||
Another way of accessing differently scoped target beans is an `ObjectFactory`/
|
||||
`Provider` injection point. See xref:core/beans/factory-scopes.adoc#beans-factory-scopes-other-injection[Scoped Beans as Dependencies].
|
||||
`Provider` injection point. See
|
||||
xref:core/beans/factory-scopes.adoc#beans-factory-scopes-other-injection[Scoped Beans as Dependencies].
|
||||
|
||||
You may also find the `ServiceLocatorFactoryBean` (in the
|
||||
`org.springframework.beans.factory.config` package) to be useful.
|
||||
====
|
||||
|
||||
|
||||
|
||||
[[beans-factory-arbitrary-method-replacement]]
|
||||
== Arbitrary Method Replacement
|
||||
|
||||
|
|
@ -422,6 +422,3 @@ substring of the fully qualified type name. For example, the following all match
|
|||
Because the number of arguments is often enough to distinguish between each possible
|
||||
choice, this shortcut can save a lot of typing, by letting you type only the
|
||||
shortest string that matches an argument type.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,10 @@
|
|||
[[beans-factory-properties-detailed]]
|
||||
= Dependencies and Configuration in Detail
|
||||
|
||||
As mentioned in the xref:core/beans/dependencies/factory-collaborators.adoc[previous section], you can define bean
|
||||
properties and constructor arguments as references to other managed beans (collaborators)
|
||||
or as values defined inline. Spring's XML-based configuration metadata supports
|
||||
sub-element types within its `<property/>` and `<constructor-arg/>` elements for this
|
||||
purpose.
|
||||
As mentioned in the xref:core/beans/dependencies/factory-collaborators.adoc[previous section],
|
||||
you can define bean properties and constructor arguments as references to other managed beans
|
||||
(collaborators) or as values defined inline. Spring's XML-based configuration metadata supports
|
||||
sub-element types within its `<property/>` and `<constructor-arg/>` elements for this purpose.
|
||||
|
||||
|
||||
[[beans-value-element]]
|
||||
|
|
@ -544,9 +543,10 @@ three approaches at the same time.
|
|||
[[beans-c-namespace]]
|
||||
== XML Shortcut with the c-namespace
|
||||
|
||||
Similar to the xref:core/beans/dependencies/factory-properties-detailed.adoc#beans-p-namespace[XML Shortcut with the p-namespace], the c-namespace, introduced in Spring
|
||||
3.1, allows inlined attributes for configuring the constructor arguments rather
|
||||
then nested `constructor-arg` elements.
|
||||
Similar to the
|
||||
xref:core/beans/dependencies/factory-properties-detailed.adoc#beans-p-namespace[XML Shortcut with the p-namespace],
|
||||
the c-namespace, introduced in Spring 3.1, allows inlined attributes for configuring
|
||||
the constructor arguments rather then nested `constructor-arg` elements.
|
||||
|
||||
The following example uses the `c:` namespace to do the same thing as the from
|
||||
xref:core/beans/dependencies/factory-collaborators.adoc#beans-constructor-injection[Constructor-based Dependency Injection]:
|
||||
|
|
@ -598,9 +598,9 @@ A corresponding index notation is also available for `<constructor-arg>` element
|
|||
not commonly used since the plain order of declaration is usually sufficient there.
|
||||
|
||||
In practice, the constructor resolution
|
||||
xref:core/beans/dependencies/factory-collaborators.adoc#beans-factory-ctor-arguments-resolution[mechanism] is quite efficient in matching
|
||||
arguments, so unless you really need to, we recommend using the name notation
|
||||
throughout your configuration.
|
||||
xref:core/beans/dependencies/factory-collaborators.adoc#beans-factory-ctor-arguments-resolution[mechanism]
|
||||
is quite efficient in matching arguments, so unless you really need to, we recommend
|
||||
using the name notation throughout your configuration.
|
||||
|
||||
|
||||
[[beans-compound-property-names]]
|
||||
|
|
@ -621,6 +621,3 @@ The `something` bean has a `fred` property, which has a `bob` property, which ha
|
|||
property, and that final `sammy` property is being set to a value of `123`. In order for
|
||||
this to work, the `fred` property of `something` and the `bob` property of `fred` must not
|
||||
be `null` after the bean is constructed. Otherwise, a `NullPointerException` is thrown.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,6 @@ user with a convenient service interface for configuring property sources and re
|
|||
properties from them.
|
||||
|
||||
|
||||
|
||||
[[beans-definition-profiles]]
|
||||
== Bean Definition Profiles
|
||||
|
||||
|
|
@ -114,7 +113,6 @@ certain contexts but not in others. You could say that you want to register a
|
|||
certain profile of bean definitions in situation A and a different profile in
|
||||
situation B. We start by updating our configuration to reflect this need.
|
||||
|
||||
|
||||
[[beans-definition-profiles-java]]
|
||||
=== Using `@Profile`
|
||||
|
||||
|
|
@ -345,7 +343,6 @@ way to represent such an arrangement in a valid Java class in the first place
|
|||
(since there can only be one method of a particular name and argument signature).
|
||||
====
|
||||
|
||||
|
||||
[[beans-definition-profiles-xml]]
|
||||
=== XML Bean Definition Profiles
|
||||
|
||||
|
|
@ -437,7 +434,6 @@ In the preceding example, the `dataSource` bean is exposed if both the `producti
|
|||
`us-east` profiles are active.
|
||||
=====
|
||||
|
||||
|
||||
[[beans-definition-profiles-enable]]
|
||||
=== Activating a Profile
|
||||
|
||||
|
|
@ -512,7 +508,6 @@ as the following example shows:
|
|||
-Dspring.profiles.active="profile1,profile2"
|
||||
----
|
||||
|
||||
|
||||
[[beans-definition-profiles-default]]
|
||||
=== Default Profile
|
||||
|
||||
|
|
@ -567,7 +562,6 @@ the default profile by using `setDefaultProfiles()` on the `Environment` or,
|
|||
declaratively, by using the `spring.profiles.default` property.
|
||||
|
||||
|
||||
|
||||
[[beans-property-source-abstraction]]
|
||||
== `PropertySource` Abstraction
|
||||
|
||||
|
|
@ -668,7 +662,6 @@ API exposes a number of methods that allow for precise manipulation of the set o
|
|||
property sources.
|
||||
|
||||
|
||||
|
||||
[[beans-using-propertysource]]
|
||||
== Using `@PropertySource`
|
||||
|
||||
|
|
@ -777,7 +770,6 @@ may also be used as a meta-annotation to create custom composed annotations with
|
|||
attribute overrides.
|
||||
|
||||
|
||||
|
||||
[[beans-placeholder-resolution-in-statements]]
|
||||
== Placeholder Resolution in Statements
|
||||
|
||||
|
|
@ -798,7 +790,3 @@ property is defined, as long as it is available in the `Environment`:
|
|||
<import resource="com/bank/service/${customer}-config.xml"/>
|
||||
</beans>
|
||||
----
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,6 @@ implementations of special integration interfaces. The next few sections describ
|
|||
integration interfaces.
|
||||
|
||||
|
||||
|
||||
[[beans-factory-extension-bpp]]
|
||||
== Customizing Beans by Using a `BeanPostProcessor`
|
||||
|
||||
|
|
@ -109,7 +108,6 @@ Spring accesses other beans for matching them by type.
|
|||
The following examples show how to write, register, and use `BeanPostProcessor` instances
|
||||
in an `ApplicationContext`.
|
||||
|
||||
|
||||
[[beans-factory-extension-bpp-examples-hw]]
|
||||
=== Example: Hello World, `BeanPostProcessor`-style
|
||||
|
||||
|
|
@ -244,7 +242,6 @@ Bean 'messenger' created : org.springframework.scripting.groovy.GroovyMessenger@
|
|||
org.springframework.scripting.groovy.GroovyMessenger@272961
|
||||
----
|
||||
|
||||
|
||||
[[beans-factory-extension-bpp-examples-aabpp]]
|
||||
=== Example: The `AutowiredAnnotationBeanPostProcessor`
|
||||
|
||||
|
|
@ -255,7 +252,6 @@ that ships with the Spring distribution and autowires annotated fields, setter m
|
|||
and arbitrary config methods.
|
||||
|
||||
|
||||
|
||||
[[beans-factory-extension-factory-postprocessors]]
|
||||
== Customizing Configuration Metadata with a `BeanFactoryPostProcessor`
|
||||
|
||||
|
|
@ -312,7 +308,6 @@ Thus, marking it for lazy initialization will be ignored, and the
|
|||
`Bean(Factory)PostProcessor` will be instantiated eagerly even if you set the
|
||||
`default-lazy-init` attribute to `true` on the declaration of your `<beans />` element.
|
||||
|
||||
|
||||
[[beans-factory-placeholderconfigurer]]
|
||||
=== Example: Property Placeholder Substitution with `PropertySourcesPlaceholderConfigurer`
|
||||
|
||||
|
|
@ -412,7 +407,6 @@ fails when it is about to be created, which is during the `preInstantiateSinglet
|
|||
phase of an `ApplicationContext` for a non-lazy-init bean.
|
||||
=====
|
||||
|
||||
|
||||
[[beans-factory-overrideconfigurer]]
|
||||
=== Example: The `PropertyOverrideConfigurer`
|
||||
|
||||
|
|
@ -469,7 +463,6 @@ property overriding with a dedicated configuration element, as the following exa
|
|||
----
|
||||
|
||||
|
||||
|
||||
[[beans-factory-extension-factorybean]]
|
||||
== Customizing Instantiation Logic with a `FactoryBean`
|
||||
|
||||
|
|
@ -502,6 +495,3 @@ calling the `getBean()` method of the `ApplicationContext`. So, for a given `Fac
|
|||
with an `id` of `myBean`, invoking `getBean("myBean")` on the container returns the
|
||||
product of the `FactoryBean`, whereas invoking `getBean("&myBean")` returns the
|
||||
`FactoryBean` instance itself.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,6 @@ of a bean. This section groups them as follows:
|
|||
* xref:core/beans/factory-nature.adoc#aware-list[Other `Aware` Interfaces]
|
||||
|
||||
|
||||
|
||||
[[beans-factory-lifecycle]]
|
||||
== Lifecycle Callbacks
|
||||
|
||||
|
|
@ -41,8 +40,6 @@ startup and shutdown process, as driven by the container's own lifecycle.
|
|||
|
||||
The lifecycle callback interfaces are described in this section.
|
||||
|
||||
|
||||
|
||||
[[beans-factory-lifecycle-initializingbean]]
|
||||
=== Initialization Callbacks
|
||||
|
||||
|
|
@ -156,8 +153,6 @@ the container's overall lifecycle management, including an auto-startup mechanis
|
|||
a pre-destroy stop step, and potential stop/restart callbacks (see below).
|
||||
====
|
||||
|
||||
|
||||
|
||||
[[beans-factory-lifecycle-disposablebean]]
|
||||
=== Destruction Callbacks
|
||||
|
||||
|
|
@ -267,8 +262,6 @@ You may also implement `SmartLifecycle` for a time-bound stop step where the con
|
|||
will wait for all such stop processing to complete before moving on to destroy methods.
|
||||
====
|
||||
|
||||
|
||||
|
||||
[[beans-factory-lifecycle-default-init-destroy-methods]]
|
||||
=== Default Initialization and Destroy Methods
|
||||
|
||||
|
|
@ -369,8 +362,6 @@ interceptors to the `init` method, because doing so would couple the lifecycle o
|
|||
target bean to its proxy or interceptors and leave strange semantics when your code
|
||||
interacts directly with the raw target bean.
|
||||
|
||||
|
||||
|
||||
[[beans-factory-lifecycle-combined-effects]]
|
||||
=== Combining Lifecycle Mechanisms
|
||||
|
||||
|
|
@ -402,8 +393,6 @@ Destroy methods are called in the same order:
|
|||
. `destroy()` as defined by the `DisposableBean` callback interface
|
||||
. A custom configured `destroy()` method
|
||||
|
||||
|
||||
|
||||
[[beans-factory-lifecycle-processor]]
|
||||
=== Startup and Shutdown Callbacks
|
||||
|
||||
|
|
@ -526,8 +515,6 @@ its own `start()` method (unlike the context refresh, the context start does not
|
|||
automatically for a standard context implementation). The `phase` value and any
|
||||
"`depends-on`" relationships determine the startup order as described earlier.
|
||||
|
||||
|
||||
|
||||
[[beans-factory-shutdown]]
|
||||
=== Shutting Down the Spring IoC Container Gracefully in Non-Web Applications
|
||||
|
||||
|
|
@ -590,8 +577,6 @@ Kotlin::
|
|||
----
|
||||
======
|
||||
|
||||
|
||||
|
||||
[[beans-factory-thread-safety]]
|
||||
=== Thread Safety and Visibility
|
||||
|
||||
|
|
@ -625,7 +610,6 @@ destroy callback without a preceding stop since this may happen during an extrao
|
|||
shutdown after a cancelled bootstrap or in case of a stop timeout caused by another bean.
|
||||
|
||||
|
||||
|
||||
[[beans-factory-aware]]
|
||||
== `ApplicationContextAware` and `BeanNameAware`
|
||||
|
||||
|
|
@ -682,7 +666,6 @@ initialization callback such as `InitializingBean.afterPropertiesSet()` or a cus
|
|||
init-method.
|
||||
|
||||
|
||||
|
||||
[[aware-list]]
|
||||
== Other `Aware` Interfaces
|
||||
|
||||
|
|
@ -747,6 +730,3 @@ dependency type. The following table summarizes the most important `Aware` inter
|
|||
Note again that using these interfaces ties your code to the Spring API and does not
|
||||
follow the Inversion of Control style. As a result, we recommend them for infrastructure
|
||||
beans that require programmatic access to the container.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -56,7 +56,6 @@ For instructions on how to register this or any other custom scope, see
|
|||
xref:core/beans/factory-scopes.adoc#beans-factory-scopes-custom-using[Using a Custom Scope].
|
||||
|
||||
|
||||
|
||||
[[beans-factory-scopes-singleton]]
|
||||
== The Singleton Scope
|
||||
|
||||
|
|
@ -91,7 +90,6 @@ following example:
|
|||
----
|
||||
|
||||
|
||||
|
||||
[[beans-factory-scopes-prototype]]
|
||||
== The Prototype Scope
|
||||
|
||||
|
|
@ -134,7 +132,6 @@ be handled by the client. (For details on the lifecycle of a bean in the Spring
|
|||
container, see xref:core/beans/factory-nature.adoc#beans-factory-lifecycle[Lifecycle Callbacks].)
|
||||
|
||||
|
||||
|
||||
[[beans-factory-scopes-sing-prot-interaction]]
|
||||
== Singleton Beans with Prototype-bean Dependencies
|
||||
|
||||
|
|
@ -152,7 +149,6 @@ and injects its dependencies. If you need a new instance of a prototype bean at
|
|||
runtime more than once, see xref:core/beans/dependencies/factory-method-injection.adoc[Method Injection].
|
||||
|
||||
|
||||
|
||||
[[beans-factory-scopes-other]]
|
||||
== Request, Session, Application, and WebSocket Scopes
|
||||
|
||||
|
|
@ -162,8 +158,6 @@ if you use a web-aware Spring `ApplicationContext` implementation (such as
|
|||
such as the `ClassPathXmlApplicationContext`, an `IllegalStateException` that complains
|
||||
about an unknown bean scope is thrown.
|
||||
|
||||
|
||||
|
||||
[[beans-factory-scopes-other-web-configuration]]
|
||||
=== Initial Web Configuration
|
||||
|
||||
|
|
@ -223,8 +217,6 @@ the same thing, namely bind the HTTP request object to the `Thread` that is serv
|
|||
that request. This makes beans that are request- and session-scoped available further
|
||||
down the call chain.
|
||||
|
||||
|
||||
|
||||
[[beans-factory-scopes-request]]
|
||||
=== Request scope
|
||||
|
||||
|
|
@ -272,8 +264,6 @@ Kotlin::
|
|||
----
|
||||
======
|
||||
|
||||
|
||||
|
||||
[[beans-factory-scopes-session]]
|
||||
=== Session Scope
|
||||
|
||||
|
|
@ -322,8 +312,6 @@ Kotlin::
|
|||
----
|
||||
======
|
||||
|
||||
|
||||
|
||||
[[beans-factory-scopes-application]]
|
||||
=== Application Scope
|
||||
|
||||
|
|
@ -371,8 +359,6 @@ Kotlin::
|
|||
----
|
||||
======
|
||||
|
||||
|
||||
|
||||
[[beans-factory-scopes-websocket]]
|
||||
=== WebSocket Scope
|
||||
|
||||
|
|
@ -380,8 +366,6 @@ WebSocket scope is associated with the lifecycle of a WebSocket session and appl
|
|||
STOMP over WebSocket applications, see
|
||||
xref:web/websocket/stomp/scope.adoc[WebSocket scope] for more details.
|
||||
|
||||
|
||||
|
||||
[[beans-factory-scopes-other-injection]]
|
||||
=== Scoped Beans as Dependencies
|
||||
|
||||
|
|
@ -539,8 +523,6 @@ interfaces. The following example shows a proxy based on an interface:
|
|||
For more detailed information about choosing class-based or interface-based proxying,
|
||||
see xref:core/aop/proxying.adoc[Proxying Mechanisms].
|
||||
|
||||
|
||||
|
||||
[[beans-factory-scopes-injection]]
|
||||
=== Injecting Request/Session References Directly
|
||||
|
||||
|
|
@ -553,7 +535,6 @@ objects which has the advantage of working in singleton beans and serializable b
|
|||
as well, similar to scoped proxies for factory-scoped beans.
|
||||
|
||||
|
||||
|
||||
[[beans-factory-scopes-custom]]
|
||||
== Custom Scopes
|
||||
|
||||
|
|
@ -561,7 +542,6 @@ The bean scoping mechanism is extensible. You can define your own
|
|||
scopes or even redefine existing scopes, although the latter is considered bad practice
|
||||
and you cannot override the built-in `singleton` and `prototype` scopes.
|
||||
|
||||
|
||||
[[beans-factory-scopes-custom-creating]]
|
||||
=== Creating a Custom Scope
|
||||
|
||||
|
|
@ -664,8 +644,6 @@ Kotlin::
|
|||
This identifier is different for each scope. For a session scoped implementation, this
|
||||
identifier can be the session identifier.
|
||||
|
||||
|
||||
|
||||
[[beans-factory-scopes-custom-using]]
|
||||
=== Using a Custom Scope
|
||||
|
||||
|
|
@ -773,7 +751,3 @@ of the scope. You can also do the `Scope` registration declaratively, by using t
|
|||
NOTE: When you place `<aop:scoped-proxy/>` within a `<bean>` declaration for a
|
||||
`FactoryBean` implementation, it is the factory bean itself that is scoped, not the object
|
||||
returned from `getObject()`.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,3 @@ by the Spring IoC container are called beans. A bean is an object that is
|
|||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4,4 +4,3 @@
|
|||
|
||||
This section covers how to use annotations in your Java code to configure the Spring
|
||||
container.
|
||||
|
||||
|
|
|
|||
|
|
@ -84,6 +84,3 @@ subclassing has to be applied at runtime, reducing the overhead and the footprin
|
|||
The `@Bean` and `@Configuration` annotations are discussed in depth in the following sections.
|
||||
First, however, we cover the various ways of creating a Spring container by using
|
||||
Java-based configuration.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -468,6 +468,7 @@ Kotlin::
|
|||
----
|
||||
======
|
||||
|
||||
|
||||
[[beans-java-customizing-bean-naming]]
|
||||
== Customizing Bean Naming
|
||||
|
||||
|
|
@ -585,6 +586,3 @@ Kotlin::
|
|||
}
|
||||
----
|
||||
======
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -905,4 +905,3 @@ Kotlin::
|
|||
}
|
||||
----
|
||||
======
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,9 @@
|
|||
`@Configuration` is a class-level annotation indicating that an object is a source of
|
||||
bean definitions. `@Configuration` classes declare beans through `@Bean`-annotated
|
||||
methods. Calls to `@Bean` methods on `@Configuration` classes can also be used to define
|
||||
inter-bean dependencies. See xref:core/beans/java/basic-concepts.adoc[Basic Concepts: `@Bean` and `@Configuration`] for a general introduction.
|
||||
inter-bean dependencies. See
|
||||
xref:core/beans/java/basic-concepts.adoc[Basic Concepts: `@Bean` and `@Configuration`]
|
||||
for a general introduction.
|
||||
|
||||
|
||||
[[beans-java-injecting-dependencies]]
|
||||
|
|
@ -58,7 +60,6 @@ is declared within a `@Configuration` class. You cannot declare inter-bean depen
|
|||
by using plain `@Component` classes.
|
||||
|
||||
|
||||
|
||||
[[beans-java-method-injection]]
|
||||
== Lookup Method Injection
|
||||
|
||||
|
|
@ -259,6 +260,3 @@ instead) or by annotating your configuration class with
|
|||
are then not intercepted, so you have to exclusively rely on dependency injection at the
|
||||
constructor or method level there.
|
||||
====
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -206,7 +206,8 @@ Kotlin::
|
|||
----
|
||||
======
|
||||
|
||||
NOTE: Remember that `@Configuration` classes are xref:core/beans/classpath-scanning.adoc#beans-meta-annotations[meta-annotated]
|
||||
NOTE: Remember that `@Configuration` classes are
|
||||
xref:core/beans/classpath-scanning.adoc#beans-meta-annotations[meta-annotated]
|
||||
with `@Component`, so they are candidates for component-scanning. In the preceding example,
|
||||
assuming that `AppConfig` is declared within the `com.acme` package (or any package
|
||||
underneath), it is picked up during the call to `scan()`. Upon `refresh()`, all its `@Bean`
|
||||
|
|
@ -280,5 +281,3 @@ NOTE: For programmatic use cases, a `GenericWebApplicationContext` can be used a
|
|||
alternative to `AnnotationConfigWebApplicationContext`. See the
|
||||
{spring-framework-api}/web/context/support/GenericWebApplicationContext.html[`GenericWebApplicationContext`]
|
||||
javadoc for details.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,6 @@ You can add the following dependency to your file pom.xml:
|
|||
=====
|
||||
|
||||
|
||||
|
||||
[[beans-inject-named]]
|
||||
== Dependency Injection with `@Inject` and `@Named`
|
||||
|
||||
|
|
@ -214,7 +213,6 @@ Kotlin::
|
|||
======
|
||||
|
||||
|
||||
|
||||
[[beans-named]]
|
||||
== `@Named` and `@ManagedBean`: Standard Equivalents to the `@Component` Annotation
|
||||
|
||||
|
|
@ -339,7 +337,6 @@ annotations are not composable. You should use Spring's stereotype model for bui
|
|||
custom component annotations.
|
||||
|
||||
|
||||
|
||||
[[beans-standard-annotations-limitations]]
|
||||
== Limitations of JSR-330 Standard Annotations
|
||||
|
||||
|
|
@ -388,6 +385,3 @@ features are not available, as the following table shows:
|
|||
only with a shorter `get()` method name. It can also be used in combination with
|
||||
Spring's `@Autowired` or with non-annotated constructors and setter methods.
|
||||
|===
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -15,8 +15,6 @@ xref:core/databuffer-codec.adoc#databuffers-buffer-pooled[pooled].
|
|||
* <<Codecs>> decode or encode data buffer streams into higher level objects.
|
||||
|
||||
|
||||
|
||||
|
||||
[[databuffers-factory]]
|
||||
== `DataBufferFactory`
|
||||
|
||||
|
|
@ -33,8 +31,6 @@ The type of factory depends on the underlying client or server, for example,
|
|||
`NettyDataBufferFactory` for Reactor Netty, `DefaultDataBufferFactory` for others.
|
||||
|
||||
|
||||
|
||||
|
||||
[[databuffers-buffer]]
|
||||
== `DataBuffer`
|
||||
|
||||
|
|
@ -50,8 +46,6 @@ alternate between read and write.
|
|||
* Determine the index, or the last index, for a given byte.
|
||||
|
||||
|
||||
|
||||
|
||||
[[databuffers-buffer-pooled]]
|
||||
== `PooledDataBuffer`
|
||||
|
||||
|
|
@ -75,8 +69,6 @@ to use the convenience methods in `DataBufferUtils` that apply release or retain
|
|||
`DataBuffer` only if it is an instance of `PooledDataBuffer`.
|
||||
|
||||
|
||||
|
||||
|
||||
[[databuffers-utils]]
|
||||
== `DataBufferUtils`
|
||||
|
||||
|
|
@ -91,8 +83,6 @@ composite buffers, if that's supported by the underlying byte buffer API.
|
|||
* Skip or take from a stream of bytes until a specific byte count.
|
||||
|
||||
|
||||
|
||||
|
||||
[[codecs]]
|
||||
== Codecs
|
||||
|
||||
|
|
@ -107,8 +97,6 @@ Jackson Smile, JAXB2, Protocol Buffers and other encoders and decoders. See
|
|||
xref:web/webflux/reactive-spring.adoc#webflux-codecs[Codecs] in the WebFlux section.
|
||||
|
||||
|
||||
|
||||
|
||||
[[databuffers-using]]
|
||||
== Using `DataBuffer`
|
||||
|
||||
|
|
|
|||
|
|
@ -54,4 +54,3 @@ The expression language supports the following functionality:
|
|||
* Collection projection
|
||||
* Collection selection
|
||||
* Templated expressions
|
||||
|
||||
|
|
|
|||
|
|
@ -217,8 +217,6 @@ Kotlin::
|
|||
======
|
||||
|
||||
|
||||
|
||||
|
||||
[[expressions-evaluation-context]]
|
||||
== Understanding `EvaluationContext`
|
||||
|
||||
|
|
@ -255,7 +253,6 @@ properties. Alternatively, configure custom accessors via
|
|||
`SimpleEvaluationContext.forPropertyAccessors(...)`, potentially disable assignment, and
|
||||
optionally activate method resolution and/or a type converter through the builder.
|
||||
|
||||
|
||||
[[expressions-type-conversion]]
|
||||
=== Type Conversion
|
||||
|
||||
|
|
@ -431,7 +428,6 @@ numeric operations, the performance gain can be very noticeable. In an example m
|
|||
benchmark run of 50,000 iterations, it took 75ms to evaluate by using the interpreter and
|
||||
only 3ms using the compiled version of the expression.
|
||||
|
||||
|
||||
[[expressions-compiler-configuration]]
|
||||
=== Compiler Configuration
|
||||
|
||||
|
|
@ -524,7 +520,6 @@ property via a JVM system property (or via the
|
|||
xref:appendix.adoc#appendix-spring-properties[`SpringProperties`] mechanism) to one of the
|
||||
`SpelCompilerMode` enum values (`off`, `immediate`, or `mixed`).
|
||||
|
||||
|
||||
[[expressions-compiler-limitations]]
|
||||
=== Compiler Limitations
|
||||
|
||||
|
|
@ -541,4 +536,3 @@ following kinds of expressions cannot be compiled.
|
|||
* Expressions using bean references
|
||||
|
||||
Compilation of additional kinds of expressions may be supported in the future.
|
||||
|
||||
|
|
|
|||
|
|
@ -133,7 +133,6 @@ The Java specification also enforces that annotations defined with `@Target(Elem
|
|||
- `Cache.@Nullable ValueWrapper`
|
||||
- `jakarta.validation.@Nullable Validator`
|
||||
|
||||
|
||||
[[null-safety-guidelines-nullaway]]
|
||||
=== NullAway
|
||||
|
||||
|
|
|
|||
|
|
@ -14,8 +14,6 @@ Spring. It includes the following topics:
|
|||
* xref:core/resources.adoc#resources-app-ctx[Application Contexts and Resource Paths]
|
||||
|
||||
|
||||
|
||||
|
||||
[[resources-introduction]]
|
||||
== Introduction
|
||||
|
||||
|
|
@ -29,8 +27,6 @@ quite complicated, and the `URL` interface still lacks some desirable functional
|
|||
such as a method to check for the existence of the resource being pointed to.
|
||||
|
||||
|
||||
|
||||
|
||||
[[resources-resource]]
|
||||
== The `Resource` Interface
|
||||
|
||||
|
|
@ -121,11 +117,8 @@ While this couples your code to Spring, it really only couples it to this small
|
|||
utility classes, which serves as a more capable replacement for `URL` and can be
|
||||
considered equivalent to any other library you would use for this purpose.
|
||||
|
||||
NOTE: The `Resource` abstraction does not replace functionality. It wraps it where
|
||||
possible. For example, a `UrlResource` wraps a URL and uses the wrapped `URL` to do its
|
||||
work.
|
||||
|
||||
|
||||
NOTE: The `Resource` abstraction does not replace functionality. It wraps it where possible.
|
||||
For example, a `UrlResource` wraps a URL and uses the wrapped `URL` to do its work.
|
||||
|
||||
|
||||
[[resources-implementations]]
|
||||
|
|
@ -145,8 +138,6 @@ For a complete list of `Resource` implementations available in Spring, consult t
|
|||
"All Known Implementing Classes" section of the
|
||||
{spring-framework-api}/core/io/Resource.html[`Resource`] javadoc.
|
||||
|
||||
|
||||
|
||||
[[resources-implementations-urlresource]]
|
||||
=== `UrlResource`
|
||||
|
||||
|
|
@ -165,8 +156,6 @@ well-known (to property editor, that is) prefix (such as `classpath:`), it creat
|
|||
appropriate specialized `Resource` for that prefix. However, if it does not recognize the
|
||||
prefix, it assumes the string is a standard URL string and creates a `UrlResource`.
|
||||
|
||||
|
||||
|
||||
[[resources-implementations-classpathresource]]
|
||||
=== `ClassPathResource`
|
||||
|
||||
|
|
@ -186,8 +175,6 @@ constructor but is often created implicitly when you call an API method that tak
|
|||
`PropertyEditor` recognizes the special prefix, `classpath:`, on the string path and
|
||||
creates a `ClassPathResource` in that case.
|
||||
|
||||
|
||||
|
||||
[[resources-implementations-filesystemresource]]
|
||||
=== `FileSystemResource`
|
||||
|
||||
|
|
@ -197,8 +184,6 @@ transformations but performing all operations via the `java.nio.file.Files` API.
|
|||
`java.nio.path.Path` based support use a `PathResource` instead. `FileSystemResource`
|
||||
supports resolution as a `File` and as a `URL`.
|
||||
|
||||
|
||||
|
||||
[[resources-implementations-pathresource]]
|
||||
=== `PathResource`
|
||||
|
||||
|
|
@ -208,8 +193,6 @@ as a `URL` and also implements the extended `WritableResource` interface. `PathR
|
|||
is effectively a pure `java.nio.path.Path` based alternative to `FileSystemResource` with
|
||||
different `createRelative` behavior.
|
||||
|
||||
|
||||
|
||||
[[resources-implementations-servletcontextresource]]
|
||||
=== `ServletContextResource`
|
||||
|
||||
|
|
@ -222,8 +205,6 @@ filesystem. Whether or not it is expanded and on the filesystem or accessed
|
|||
directly from the JAR or somewhere else like a database (which is conceivable) is actually
|
||||
dependent on the Servlet container.
|
||||
|
||||
|
||||
|
||||
[[resources-implementations-inputstreamresource]]
|
||||
=== `InputStreamResource`
|
||||
|
||||
|
|
@ -237,8 +218,6 @@ already-opened resource. Therefore, it returns `true` from `isOpen()`. Do not us
|
|||
you need to keep the resource descriptor somewhere or if you need to read a stream
|
||||
multiple times.
|
||||
|
||||
|
||||
|
||||
[[resources-implementations-bytearrayresource]]
|
||||
=== `ByteArrayResource`
|
||||
|
||||
|
|
@ -249,8 +228,6 @@ It is useful for loading content from any given byte array without having to res
|
|||
single-use `InputStreamResource`.
|
||||
|
||||
|
||||
|
||||
|
||||
[[resources-resourceloader]]
|
||||
== The `ResourceLoader` Interface
|
||||
|
||||
|
|
@ -385,8 +362,6 @@ objects:
|
|||
|===
|
||||
|
||||
|
||||
|
||||
|
||||
[[resources-resourcepatternresolver]]
|
||||
== The `ResourcePatternResolver` Interface
|
||||
|
||||
|
|
@ -436,8 +411,6 @@ implements the `ResourcePatternResolver` interface and delegates to the default
|
|||
====
|
||||
|
||||
|
||||
|
||||
|
||||
[[resources-resourceloaderaware]]
|
||||
== The `ResourceLoaderAware` Interface
|
||||
|
||||
|
|
@ -483,8 +456,6 @@ xref:core/resources.adoc#resources-resourcepatternresolver[`ResourcePatternResol
|
|||
application components instead of `ResourceLoader`.
|
||||
|
||||
|
||||
|
||||
|
||||
[[resources-as-dependencies]]
|
||||
== Resources as Dependencies
|
||||
|
||||
|
|
@ -631,16 +602,12 @@ Kotlin::
|
|||
======
|
||||
|
||||
|
||||
|
||||
|
||||
[[resources-app-ctx]]
|
||||
== Application Contexts and Resource Paths
|
||||
|
||||
This section covers how to create application contexts with resources, including shortcuts
|
||||
that work with XML, how to use wildcards, and other details.
|
||||
|
||||
|
||||
|
||||
[[resources-app-ctx-construction]]
|
||||
=== Constructing Application Contexts
|
||||
|
||||
|
|
@ -720,7 +687,6 @@ Using `FileSystemXmlApplicationContext` loads the bean definitions from the clas
|
|||
However, it is still a `FileSystemXmlApplicationContext`. If it is subsequently used as a
|
||||
`ResourceLoader`, any unprefixed paths are still treated as filesystem paths.
|
||||
|
||||
|
||||
[[resources-app-ctx-classpathxml]]
|
||||
==== Constructing `ClassPathXmlApplicationContext` Instances -- Shortcuts
|
||||
|
||||
|
|
@ -766,8 +732,6 @@ Kotlin::
|
|||
See the {spring-framework-api}/context/support/ClassPathXmlApplicationContext.html[`ClassPathXmlApplicationContext`]
|
||||
javadoc for details on the various constructors.
|
||||
|
||||
|
||||
|
||||
[[resources-app-ctx-wildcards-in-resource-paths]]
|
||||
=== Wildcards in Application Context Constructor Resource Paths
|
||||
|
||||
|
|
@ -788,7 +752,6 @@ resolved at construction time. It has nothing to do with the `Resource` type its
|
|||
You cannot use the `classpath*:` prefix to construct an actual `Resource`, as
|
||||
a resource points to just one resource at a time.
|
||||
|
||||
|
||||
[[resources-app-ctx-ant-patterns-in-paths]]
|
||||
==== Ant-style Patterns
|
||||
|
||||
|
|
@ -832,7 +795,6 @@ walk the contents of the jar and resolve the wildcard. This does work in most en
|
|||
but fails in others, and we strongly recommend that the wildcard resolution of resources
|
||||
coming from jars be thoroughly tested in your specific environment before you rely on it.
|
||||
|
||||
|
||||
[[resources-classpath-wildcards]]
|
||||
==== The `classpath*:` Prefix
|
||||
|
||||
|
|
@ -880,7 +842,6 @@ used on the last non-wildcard path segment to get all the matching resources in
|
|||
class loader hierarchy and then, off each resource, the same `PathMatcher` resolution
|
||||
strategy described earlier is used for the wildcard subpath.
|
||||
|
||||
|
||||
[[resources-wildcards-in-path-other-stuff]]
|
||||
==== Other Notes Relating to Wildcards
|
||||
|
||||
|
|
@ -934,8 +895,6 @@ location found. Therefore, in such cases you should prefer using `classpath*:` w
|
|||
same Ant-style pattern, which searches all classpath locations that contain the
|
||||
`com.mycompany` base package: `classpath*:com/mycompany/**/service-context.xml`.
|
||||
|
||||
|
||||
|
||||
[[resources-filesystemresource-caveats]]
|
||||
=== `FileSystemResource` Caveats
|
||||
|
||||
|
|
|
|||
|
|
@ -30,11 +30,8 @@ implementations. They are also discussed in this chapter.
|
|||
|
||||
Spring supports Java Bean Validation through setup infrastructure and an adaptor to
|
||||
Spring's own `Validator` contract. Applications can enable Bean Validation once globally,
|
||||
as described in xref:core/validation/beanvalidation.adoc[Java Bean Validation], and use it exclusively for all validation
|
||||
needs. In the web layer, applications can further register controller-local Spring
|
||||
`Validator` instances per `DataBinder`, as described in xref:core/validation/beanvalidation.adoc#validation-binder[Configuring a `DataBinder`], which can
|
||||
be useful for plugging in custom validation logic.
|
||||
|
||||
|
||||
|
||||
|
||||
as described in xref:core/validation/beanvalidation.adoc[Java Bean Validation], and use
|
||||
it exclusively for all validation needs. In the web layer, applications can further
|
||||
register controller-local Spring `Validator` instances per `DataBinder`, as described in
|
||||
xref:core/validation/beanvalidation.adoc#validation-binder[Configuring a `DataBinder`],
|
||||
which can be useful for plugging in custom validation logic.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ The Spring Framework provides support for the
|
|||
{bean-validation-site}[Java Bean Validation] API.
|
||||
|
||||
|
||||
|
||||
[[validation-beanvalidation-overview]]
|
||||
== Overview of Bean Validation
|
||||
|
||||
|
|
@ -78,7 +77,6 @@ specific constraints. To learn how to set up a bean validation provider as a Spr
|
|||
bean, keep reading.
|
||||
|
||||
|
||||
|
||||
[[validation-beanvalidation-spring]]
|
||||
== Configuring a Bean Validation Provider
|
||||
|
||||
|
|
@ -121,7 +119,6 @@ The basic configuration in the preceding example triggers bean validation to ini
|
|||
using its default bootstrap mechanism. A Bean Validation provider, such as the Hibernate
|
||||
Validator, is expected to be present in the classpath and is automatically detected.
|
||||
|
||||
|
||||
[[validation-beanvalidation-spring-inject]]
|
||||
=== Inject Jakarta Validator
|
||||
|
||||
|
|
@ -157,7 +154,6 @@ Kotlin::
|
|||
----
|
||||
======
|
||||
|
||||
|
||||
[[validation-beanvalidation-spring-inject-adapter]]
|
||||
=== Inject Spring Validator
|
||||
|
||||
|
|
@ -199,8 +195,6 @@ invokes the underlying `jakarta.validation.Validator`, and then adapts
|
|||
``ConstraintViolation``s to ``FieldError``s, and registers them with the `Errors` object
|
||||
passed into the `validate` method.
|
||||
|
||||
|
||||
|
||||
[[validation-beanvalidation-spring-constraints]]
|
||||
=== Configure Custom Constraints
|
||||
|
||||
|
|
@ -276,7 +270,6 @@ Kotlin::
|
|||
----
|
||||
======
|
||||
|
||||
|
||||
As the preceding example shows, a `ConstraintValidator` implementation can have its dependencies
|
||||
`@Autowired` as any other Spring bean.
|
||||
|
||||
|
|
@ -311,7 +304,6 @@ xref:web/webmvc/mvc-ann-rest-exceptions.adoc[Error Responses] sections, and the
|
|||
xref:web/webflux/controller/ann-validation.adoc[Validation] and
|
||||
xref:web/webflux/ann-rest-exceptions.adoc[Error Responses] sections.
|
||||
|
||||
|
||||
[[validation-beanvalidation-spring-method-exceptions]]
|
||||
=== Method Validation Exceptions
|
||||
|
||||
|
|
@ -330,7 +322,6 @@ fields and properties, the `ParameterValidationResult` is `ParameterErrors` whic
|
|||
implements `org.springframework.validation.Errors` and exposes validation errors as
|
||||
``FieldError``s.
|
||||
|
||||
|
||||
[[validation-beanvalidation-spring-method-i18n]]
|
||||
=== Customizing Validation Errors
|
||||
|
||||
|
|
@ -411,7 +402,6 @@ Properties::
|
|||
Max.degrees=You cannot provide more than {1} {0}
|
||||
----
|
||||
|
||||
|
||||
[[validation-beanvalidation-spring-other]]
|
||||
=== Additional Configuration Options
|
||||
|
||||
|
|
@ -422,7 +412,6 @@ constructs, from message interpolation to traversal resolution. See the
|
|||
javadoc for more information on these options.
|
||||
|
||||
|
||||
|
||||
[[validation-binder]]
|
||||
== Configuring a `DataBinder`
|
||||
|
||||
|
|
@ -479,8 +468,7 @@ locally on a DataBinder instance. See
|
|||
xref:web/webmvc/mvc-config/validation.adoc[Spring MVC Validation Configuration].
|
||||
|
||||
|
||||
|
||||
[[validation-mvc]]
|
||||
== Spring MVC 3 Validation
|
||||
== Spring MVC Validation
|
||||
|
||||
See xref:web/webmvc/mvc-config/validation.adoc[Validation] in the Spring MVC chapter.
|
||||
|
|
|
|||
|
|
@ -9,7 +9,6 @@ the required property types. You can also use the public API anywhere in your ap
|
|||
where type conversion is needed.
|
||||
|
||||
|
||||
|
||||
[[core-convert-Converter-API]]
|
||||
== Converter SPI
|
||||
|
||||
|
|
@ -54,7 +53,6 @@ The following listing shows the `StringToInteger` class, which is a typical `Con
|
|||
----
|
||||
|
||||
|
||||
|
||||
[[core-convert-ConverterFactory-SPI]]
|
||||
== Using `ConverterFactory`
|
||||
|
||||
|
|
@ -146,7 +144,6 @@ NOTE: Because `GenericConverter` is a more complex SPI interface, you should use
|
|||
it only when you need it. Favor `Converter` or `ConverterFactory` for basic type
|
||||
conversion needs.
|
||||
|
||||
|
||||
[[core-convert-ConditionalGenericConverter-SPI]]
|
||||
=== Using `ConditionalGenericConverter`
|
||||
|
||||
|
|
@ -175,7 +172,6 @@ might match only if the target entity type declares a static finder method (for
|
|||
`matches(TypeDescriptor, TypeDescriptor)`.
|
||||
|
||||
|
||||
|
||||
[[core-convert-ConversionService-API]]
|
||||
== The `ConversionService` API
|
||||
|
||||
|
|
@ -208,7 +204,6 @@ use in most environments. `ConversionServiceFactory` provides a convenient facto
|
|||
creating common `ConversionService` configurations.
|
||||
|
||||
|
||||
|
||||
[[core-convert-Spring-config]]
|
||||
== Configuring a `ConversionService`
|
||||
|
||||
|
|
@ -256,7 +251,6 @@ xref:core/validation/format.adoc#format-FormatterRegistry-SPI[The `FormatterRegi
|
|||
for details on using `FormattingConversionServiceFactoryBean`.
|
||||
|
||||
|
||||
|
||||
[[core-convert-programmatic-usage]]
|
||||
== Using a `ConversionService` Programmatically
|
||||
|
||||
|
|
|
|||
|
|
@ -22,4 +22,3 @@ in the javadoc of
|
|||
{spring-framework-api}/validation/MessageCodesResolver.html[`MessageCodesResolver`] and
|
||||
{spring-framework-api}/validation/DefaultMessageCodesResolver.html[`DefaultMessageCodesResolver`],
|
||||
respectively.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,6 +19,3 @@ Note there are extra considerations when configuring date and time formats in we
|
|||
applications. Please see
|
||||
xref:web/webmvc/mvc-config/conversion.adoc[WebMVC Conversion and Formatting] or
|
||||
xref:web/webflux/config.adoc#webflux-config-conversion[WebFlux Conversion and Formatting].
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,6 @@ application) and need to parse and print localized field values. The `Conversion
|
|||
provides a unified type conversion API for both SPIs.
|
||||
|
||||
|
||||
|
||||
[[format-Formatter-SPI]]
|
||||
== The `Formatter` SPI
|
||||
|
||||
|
|
@ -143,7 +142,6 @@ The Spring team welcomes community-driven `Formatter` contributions. See
|
|||
{spring-framework-issues}[GitHub Issues] to contribute.
|
||||
|
||||
|
||||
|
||||
[[format-CustomFormatAnnotations]]
|
||||
== Annotation-driven Formatting
|
||||
|
||||
|
|
@ -275,7 +273,6 @@ Kotlin::
|
|||
----
|
||||
======
|
||||
|
||||
|
||||
[[format-annotations-api]]
|
||||
=== Format Annotation API
|
||||
|
||||
|
|
@ -335,6 +332,7 @@ https://github.com/spring-projects/spring-framework/wiki/Date-and-Time-Formattin
|
|||
page in the Spring Framework wiki.
|
||||
====
|
||||
|
||||
|
||||
[[format-FormatterRegistry-SPI]]
|
||||
== The `FormatterRegistry` SPI
|
||||
|
||||
|
|
@ -376,7 +374,6 @@ annotation are formatted in a certain way. With a shared `FormatterRegistry`, yo
|
|||
these rules once, and they are applied whenever formatting is needed.
|
||||
|
||||
|
||||
|
||||
[[format-FormatterRegistrar-SPI]]
|
||||
== The `FormatterRegistrar` SPI
|
||||
|
||||
|
|
@ -401,12 +398,7 @@ registering a `Printer`/`Parser` pair. The next section provides more informatio
|
|||
converter and formatter registration.
|
||||
|
||||
|
||||
|
||||
[[format-configuring-formatting-mvc]]
|
||||
== Configuring Formatting in Spring MVC
|
||||
|
||||
See xref:web/webmvc/mvc-config/conversion.adoc[Conversion and Formatting] in the Spring MVC chapter.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -201,6 +201,3 @@ not involving a binding process. As of 6.1, this has been simplified through a n
|
|||
a simple `Errors` representation which can be inspected: typically calling `hasErrors()`
|
||||
or the new `failOnError` method for turning the error summary message into an exception
|
||||
(for example, `validator.validateObject(myObject).failOnError(IllegalArgumentException::new)`).
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,3 @@ interaction between the data access layer and the business or service layer.
|
|||
Spring's comprehensive transaction management support is covered in some detail,
|
||||
followed by thorough coverage of the various data access frameworks and technologies
|
||||
with which the Spring Framework integrates.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
= Appendix
|
||||
|
||||
|
||||
|
||||
|
||||
[[xsd-schemas]]
|
||||
== XML Schemas
|
||||
|
||||
|
|
@ -12,8 +10,6 @@ This part of the appendix lists XML schemas for data access, including the follo
|
|||
* xref:data-access/appendix.adoc#xsd-schemas-tx[The `tx` Schema]
|
||||
* xref:data-access/appendix.adoc#xsd-schemas-jdbc[The `jdbc` Schema]
|
||||
|
||||
|
||||
|
||||
[[xsd-schemas-tx]]
|
||||
=== The `tx` Schema
|
||||
|
||||
|
|
@ -61,8 +57,6 @@ implemented by using AOP). The preceding XML snippet contains the relevant lines
|
|||
to reference the `aop` schema so that the elements in the `aop` namespace are available
|
||||
to you.
|
||||
|
||||
|
||||
|
||||
[[xsd-schemas-jdbc]]
|
||||
=== The `jdbc` Schema
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,6 @@ and it also lets you code without worrying about catching exceptions that are
|
|||
specific to each technology.
|
||||
|
||||
|
||||
|
||||
[[dao-exceptions]]
|
||||
== Consistent Exception Hierarchy
|
||||
|
||||
|
|
@ -42,7 +41,6 @@ The following image shows the exception hierarchy that Spring provides.
|
|||
image::DataAccessException.png[]
|
||||
|
||||
|
||||
|
||||
[[dao-annotations]]
|
||||
== Annotations Used to Configure DAO or Repository Classes
|
||||
|
||||
|
|
@ -192,7 +190,3 @@ Kotlin::
|
|||
|
||||
NOTE: See the specific coverage of each persistence technology for details on how to
|
||||
configure the application context to take advantage of these annotations.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -53,6 +53,3 @@ takes care of and which actions are your responsibility.
|
|||
|
||||
The Spring Framework takes care of all the low-level details that can make JDBC such a
|
||||
tedious API.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -312,6 +312,3 @@ each batch should be the batch size provided for all batches (except that the la
|
|||
that might be less), depending on the total number of update objects provided. The update
|
||||
count for each update statement is the one reported by the JDBC driver. If the count is
|
||||
not available, the JDBC driver returns a value of `-2`.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -22,6 +22,3 @@ and match to include a feature from a different approach.
|
|||
data-access layer. This approach allows you to define your query string, declare
|
||||
parameters, and compile the query. Once you do that, `execute(...)`, `update(...)`, and
|
||||
`findObject(...)` methods can be called multiple times with various parameter values.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -62,6 +62,7 @@ The following example shows C3P0 configuration:
|
|||
|
||||
include-code::./ComboPooledDataSourceConfiguration[tag=snippet,indent=0]
|
||||
|
||||
|
||||
[[jdbc-DataSourceUtils]]
|
||||
== Using `DataSourceUtils`
|
||||
|
||||
|
|
@ -196,6 +197,3 @@ In terms of exception behavior, `JdbcTransactionManager` is roughly equivalent t
|
|||
`JpaTransactionManager` and also to `R2dbcTransactionManager`, serving as an immediate
|
||||
companion/replacement for each other. `DataSourceTransactionManager` on the other hand
|
||||
is equivalent to `JtaTransactionManager` and can serve as a direct replacement there.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1081,6 +1081,3 @@ Kotlin::
|
|||
// keyHolder.getKey() now contains the generated key
|
||||
----
|
||||
======
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -255,6 +255,3 @@ You can extend Spring JDBC embedded database support in two ways:
|
|||
|
||||
We encourage you to contribute extensions to the Spring community at
|
||||
{spring-framework-issues}[GitHub Issues].
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -141,6 +141,3 @@ Ensuring that the database initializer is initialized first can also be easy. So
|
|||
parent context contains the `DataSource`, and the child context contains the business
|
||||
components). This structure is common in Spring web applications but can be more
|
||||
generally applied.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -599,6 +599,3 @@ Kotlin::
|
|||
}
|
||||
----
|
||||
======
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,9 @@ and its various callback interfaces, plus a variety of related classes. A subpac
|
|||
named `org.springframework.jdbc.core.simple` contains the `SimpleJdbcInsert` and
|
||||
`SimpleJdbcCall` classes. Another subpackage named
|
||||
`org.springframework.jdbc.core.namedparam` contains the `NamedParameterJdbcTemplate`
|
||||
class and the related support classes. See xref:data-access/jdbc/core.adoc[Using the JDBC Core Classes to Control Basic JDBC Processing and Error Handling], xref:data-access/jdbc/advanced.adoc[JDBC Batch Operations], and
|
||||
class and the related support classes. See
|
||||
xref:data-access/jdbc/core.adoc[Using the JDBC Core Classes to Control Basic JDBC Processing and Error Handling],
|
||||
xref:data-access/jdbc/advanced.adoc[JDBC Batch Operations], and
|
||||
xref:data-access/jdbc/simple.adoc[Simplifying JDBC Operations with the `SimpleJdbc` Classes].
|
||||
|
||||
* `datasource`: The `org.springframework.jdbc.datasource` package contains a utility class
|
||||
|
|
@ -16,7 +18,8 @@ for easy `DataSource` access and various simple `DataSource` implementations tha
|
|||
use for testing and running unmodified JDBC code outside of a Jakarta EE container. A subpackage
|
||||
named `org.springframework.jdbc.datasource.embedded` provides support for creating
|
||||
embedded databases by using Java database engines, such as HSQL, H2, and Derby. See
|
||||
xref:data-access/jdbc/connections.adoc[Controlling Database Connections] and xref:data-access/jdbc/embedded-database-support.adoc[Embedded Database Support].
|
||||
xref:data-access/jdbc/connections.adoc[Controlling Database Connections] and
|
||||
xref:data-access/jdbc/embedded-database-support.adoc[Embedded Database Support].
|
||||
|
||||
* `object`: The `org.springframework.jdbc.object` package contains classes that represent
|
||||
RDBMS queries, updates, and stored procedures as thread-safe, reusable objects. See
|
||||
|
|
@ -31,7 +34,5 @@ are translated to exceptions defined in the `org.springframework.dao` package. T
|
|||
that code using the Spring JDBC abstraction layer does not need to implement JDBC or
|
||||
RDBMS-specific error handling. All translated exceptions are unchecked, which gives you
|
||||
the option of catching the exceptions from which you can recover while letting other
|
||||
exceptions be propagated to the caller. See xref:data-access/jdbc/core.adoc#jdbc-SQLExceptionTranslator[Using `SQLExceptionTranslator`].
|
||||
|
||||
|
||||
|
||||
exceptions be propagated to the caller. See
|
||||
xref:data-access/jdbc/core.adoc#jdbc-SQLExceptionTranslator[Using `SQLExceptionTranslator`].
|
||||
|
|
|
|||
|
|
@ -231,4 +231,3 @@ access by unwrapping it. You can use the `SqlTypeValue` to create an array and p
|
|||
it with values from the Java `java.sql.Array`, as the following example shows:
|
||||
|
||||
include-code::./SqlTypeValueFactory[tag=oracle-array,indent=0]
|
||||
|
||||
|
|
|
|||
|
|
@ -768,6 +768,3 @@ Kotlin::
|
|||
|
||||
The `execute` call passes in an empty `Map`, because this call does not take any parameters.
|
||||
The list of actors is then retrieved from the results map and returned to the caller.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -3,6 +3,3 @@
|
|||
:page-section-summary-toc: 1
|
||||
|
||||
This section covers data access when you use Object Relational Mapping (ORM).
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -109,6 +109,3 @@ In summary, you can implement DAOs based on the plain persistence technology's A
|
|||
annotations while still benefiting from Spring-managed transactions, dependency
|
||||
injection, and transparent exception conversion (if desired) to Spring's custom
|
||||
exception hierarchies.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -514,6 +514,3 @@ the following events occur when a JTA transaction commits:
|
|||
* Hibernate is synchronized to the JTA transaction, so the transaction is called back
|
||||
through an `afterCompletion` callback by the JTA transaction manager and can
|
||||
properly clear its cache.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,8 @@ The benefits of using the Spring Framework to create your ORM DAOs include:
|
|||
aspect-oriented programming (AOP) style method interceptor either through the
|
||||
`@Transactional` annotation or by explicitly configuring the transaction AOP advice in
|
||||
an XML configuration file. In both cases, transaction semantics and exception handling
|
||||
(rollback and so on) are handled for you. As discussed in xref:data-access/orm/general.adoc#orm-resource-mngmnt[Resource and Transaction Management],
|
||||
(rollback and so on) are handled for you. As discussed in
|
||||
xref:data-access/orm/general.adoc#orm-resource-mngmnt[Resource and Transaction Management],
|
||||
you can also swap various transaction managers, without affecting your ORM-related code.
|
||||
For example, you can swap between local transactions and JTA, with the same full services
|
||||
(such as declarative transactions) available in both scenarios. Additionally,
|
||||
|
|
@ -61,6 +62,3 @@ technologies such as MongoDB, you might want to check out the
|
|||
{spring-site-projects}/spring-data/[Spring Data] suite of projects. If you are
|
||||
a JPA user, the {spring-site-guides}/gs/accessing-data-jpa/[Getting Started Accessing
|
||||
Data with JPA] guide from https://spring.io provides a great introduction.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -627,7 +627,3 @@ On `LocalSessionFactoryBean`, this is available through the `bootstrapExecutor`
|
|||
property. On the programmatic `LocalSessionFactoryBuilder`, an overloaded
|
||||
`buildSessionFactory` method takes a bootstrap executor argument.
|
||||
====
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,6 @@
|
|||
= Marshalling XML by Using Object-XML Mappers
|
||||
|
||||
|
||||
|
||||
[[oxm-introduction]]
|
||||
== Introduction
|
||||
|
||||
|
|
@ -22,7 +21,6 @@ Some of the benefits of using Spring for your O/X mapping needs are:
|
|||
* xref:data-access/oxm.adoc#oxm-consistent-interfaces[Consistent Interfaces]
|
||||
* xref:data-access/oxm.adoc#oxm-consistent-exception-hierarchy[Consistent Exception Hierarchy]
|
||||
|
||||
|
||||
[[oxm-ease-of-configuration]]
|
||||
=== Ease of configuration
|
||||
|
||||
|
|
@ -32,7 +30,6 @@ as you would any other bean in your application context. Additionally, XML names
|
|||
configuration is available for a number of marshallers, making the configuration even
|
||||
simpler.
|
||||
|
||||
|
||||
[[oxm-consistent-interfaces]]
|
||||
=== Consistent Interfaces
|
||||
|
||||
|
|
@ -44,7 +41,6 @@ marshalling with a mix-and-match approach (for example, some marshalling perform
|
|||
and some by XStream) in a non-intrusive fashion, letting you use the strength of each
|
||||
technology.
|
||||
|
||||
|
||||
[[oxm-consistent-exception-hierarchy]]
|
||||
=== Consistent Exception Hierarchy
|
||||
|
||||
|
|
@ -53,7 +49,6 @@ own exception hierarchy with the `XmlMappingException` as the root exception.
|
|||
These runtime exceptions wrap the original exception so that no information is lost.
|
||||
|
||||
|
||||
|
||||
[[oxm-marshaller-unmarshaller]]
|
||||
== `Marshaller` and `Unmarshaller`
|
||||
|
||||
|
|
@ -61,7 +56,6 @@ As stated in the xref:data-access/oxm.adoc#oxm-introduction[introduction], a mar
|
|||
to XML, and an unmarshaller deserializes XML stream to an object. This section describes
|
||||
the two Spring interfaces used for this purpose.
|
||||
|
||||
|
||||
[[oxm-marshaller]]
|
||||
=== Understanding `Marshaller`
|
||||
|
||||
|
|
@ -104,7 +98,6 @@ must be mapped in a mapping file, be marked with an annotation, be registered wi
|
|||
marshaller, or have a common base class. Refer to the later sections in this chapter
|
||||
to determine how your O-X technology manages this.
|
||||
|
||||
|
||||
[[oxm-unmarshaller]]
|
||||
=== Understanding `Unmarshaller`
|
||||
|
||||
|
|
@ -146,7 +139,6 @@ Even though there are two separate marshalling interfaces (`Marshaller` and
|
|||
This means that you can wire up one marshaller class and refer to it both as a
|
||||
marshaller and as an unmarshaller in your `applicationContext.xml`.
|
||||
|
||||
|
||||
[[oxm-xmlmappingexception]]
|
||||
=== Understanding `XmlMappingException`
|
||||
|
||||
|
|
@ -163,7 +155,6 @@ The O-X Mapping exception hierarchy is shown in the following figure:
|
|||
image::oxm-exceptions.png[]
|
||||
|
||||
|
||||
|
||||
[[oxm-usage]]
|
||||
== Using `Marshaller` and `Unmarshaller`
|
||||
|
||||
|
|
@ -319,7 +310,6 @@ This sample application produces the following `settings.xml` file:
|
|||
----
|
||||
|
||||
|
||||
|
||||
[[oxm-schema-based-config]]
|
||||
== XML Configuration Namespace
|
||||
|
||||
|
|
@ -356,7 +346,6 @@ the configuration of a JAXB2 marshaller might resemble the following:
|
|||
----
|
||||
|
||||
|
||||
|
||||
[[oxm-jaxb]]
|
||||
== JAXB
|
||||
|
||||
|
|
@ -369,7 +358,6 @@ Spring supports the JAXB 2.0 API as XML marshalling strategies, following the
|
|||
The corresponding integration classes reside in the `org.springframework.oxm.jaxb`
|
||||
package.
|
||||
|
||||
|
||||
[[oxm-jaxb2]]
|
||||
=== Using `Jaxb2Marshaller`
|
||||
|
||||
|
|
@ -436,7 +424,6 @@ The following table describes the available attributes:
|
|||
|===
|
||||
|
||||
|
||||
|
||||
[[oxm-jibx]]
|
||||
== JiBX
|
||||
|
||||
|
|
@ -450,7 +437,6 @@ For more information on JiBX, see the http://jibx.sourceforge.net/[JiBX web
|
|||
site]. The Spring integration classes reside in the `org.springframework.oxm.jibx`
|
||||
package.
|
||||
|
||||
|
||||
[[oxm-jibx-marshaller]]
|
||||
=== Using `JibxMarshaller`
|
||||
|
||||
|
|
@ -503,7 +489,6 @@ The following table describes the available attributes:
|
|||
|===
|
||||
|
||||
|
||||
|
||||
[[oxm-xstream]]
|
||||
== XStream
|
||||
|
||||
|
|
@ -514,7 +499,6 @@ For more information on XStream, see the https://x-stream.github.io/[XStream
|
|||
web site]. The Spring integration classes reside in the
|
||||
`org.springframework.oxm.xstream` package.
|
||||
|
||||
|
||||
[[oxm-xstream-marshaller]]
|
||||
=== Using `XStreamMarshaller`
|
||||
|
||||
|
|
@ -557,16 +541,14 @@ set the `supportedClasses` property on the `XStreamMarshaller`, as the following
|
|||
Doing so ensures that only the registered classes are eligible for unmarshalling.
|
||||
|
||||
Additionally, you can register
|
||||
{spring-framework-api}/oxm/xstream/XStreamMarshaller.html#setConverters(com.thoughtworks.xstream.converters.ConverterMatcher...)[custom
|
||||
converters] to make sure that only your supported classes can be unmarshalled. You might
|
||||
want to add a `CatchAllConverter` as the last converter in the list, in addition to
|
||||
converters that explicitly support the domain classes that should be supported. As a
|
||||
result, default XStream converters with lower priorities and possible security
|
||||
{spring-framework-api}/oxm/xstream/XStreamMarshaller.html#setConverters(com.thoughtworks.xstream.converters.ConverterMatcher...)[custom converters]
|
||||
to make sure that only your supported classes can be unmarshalled. You might want
|
||||
to add a `CatchAllConverter` as the last converter in the list, in addition to
|
||||
converters that explicitly support the domain classes that should be supported.
|
||||
As a result, default XStream converters with lower priorities and possible security
|
||||
vulnerabilities do not get invoked.
|
||||
=====
|
||||
|
||||
NOTE: Note that XStream is an XML serialization library, not a data binding library.
|
||||
Therefore, it has limited namespace support. As a result, it is rather unsuitable for usage
|
||||
within Web Services.
|
||||
|
||||
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue