Merge PDF reference documentation into single file
This commit configures the documentation build to merge the entire reference documentation into a single PDF file. To achieve that, this commit also fixes duplicate anchors that were introduced while factoring out common parts of the documentation for MVC and WebFlux. Closes gh-28451
This commit is contained in:
Brian Clozel
parent
af8518ab1e
commit
4b22a4a0d8
|
|
@ -130,7 +130,7 @@ asciidoctorPdf {
|
|||
baseDirFollowsSourceDir()
|
||||
configurations 'asciidoctorExtensions'
|
||||
sources {
|
||||
include '*.adoc'
|
||||
include 'spring-framework.adocbook'
|
||||
}
|
||||
outputDir "$buildDir/docs/ref-docs/pdf"
|
||||
forkOptions {
|
||||
|
|
|
|||
|
|
@ -262,8 +262,8 @@ element, as the following example shows:
|
|||
----
|
||||
|
||||
This assumes that you use schema support as described in
|
||||
<<core.adoc#xsd-schemas, XML Schema-based configuration>>.
|
||||
See <<core.adoc#xsd-schemas-aop, the AOP schema>> for how to
|
||||
<<core.adoc#core.appendix.xsd-schemas, XML Schema-based configuration>>.
|
||||
See <<core.adoc#core.appendix.xsd-schemas-aop, the AOP schema>> for how to
|
||||
import the tags in the `aop` namespace.
|
||||
|
||||
|
||||
|
|
@ -1991,8 +1991,8 @@ that syntax and refer the reader to the discussion in the previous section
|
|||
of advice parameters.
|
||||
|
||||
To use the aop namespace tags described in this section, you need to import the
|
||||
`spring-aop` schema, as described in <<core.adoc#xsd-schemas,
|
||||
XML Schema-based configuration>>. See <<core.adoc#xsd-schemas-aop, the AOP schema>>
|
||||
`spring-aop` schema, as described in <<core.adoc#core.appendix.xsd-schemas,
|
||||
XML Schema-based configuration>>. See <<core.adoc#core.appendix.xsd-schemas-aop, the AOP schema>>
|
||||
for how to import the tags in the `aop` namespace.
|
||||
|
||||
Within your Spring configurations, all aspect and advisor elements must be placed within
|
||||
|
|
@ -3502,7 +3502,7 @@ use Java-based configuration, you can add `@EnableSpringConfigured` to any
|
|||
----
|
||||
|
||||
If you prefer XML based configuration, the Spring
|
||||
<<core.adoc#xsd-schemas-context, `context` namespace>>
|
||||
<<core.adoc#core.appendix.xsd-schemas-context, `context` namespace>>
|
||||
defines a convenient `context:spring-configured` element, which you can use as follows:
|
||||
|
||||
[source,xml,indent=0,subs="verbatim,quotes"]
|
||||
|
|
|
|||
|
|
@ -1,16 +1,17 @@
|
|||
[[core.appendix]]
|
||||
= Appendix
|
||||
|
||||
|
||||
|
||||
|
||||
[[xsd-schemas]]
|
||||
[[core.appendix.xsd-schemas]]
|
||||
== XML Schemas
|
||||
|
||||
This part of the appendix lists XML schemas related to the core container.
|
||||
|
||||
|
||||
|
||||
[[xsd-schemas-util]]
|
||||
[[core.appendix.xsd-schemas-util]]
|
||||
=== The `util` Schema
|
||||
|
||||
As the name implies, the `util` tags deal with common, utility configuration
|
||||
|
|
@ -35,7 +36,7 @@ correct schema so that the tags in the `util` namespace are available to you):
|
|||
----
|
||||
|
||||
|
||||
[[xsd-schemas-util-constant]]
|
||||
[[core.appendix.xsd-schemas-util-constant]]
|
||||
==== Using `<util:constant/>`
|
||||
|
||||
Consider the following bean definition:
|
||||
|
|
@ -68,7 +69,7 @@ developer's intent ("`inject this constant value`"), and it reads better:
|
|||
</bean>
|
||||
----
|
||||
|
||||
[[xsd-schemas-util-frfb]]
|
||||
[[core.appendix.xsd-schemas-util-frfb]]
|
||||
===== Setting a Bean Property or Constructor Argument from a Field Value
|
||||
|
||||
{api-spring-framework}/beans/factory/config/FieldRetrievingFactoryBean.html[`FieldRetrievingFactoryBean`]
|
||||
|
|
@ -180,7 +181,7 @@ Now consider the following setter of type `PersistenceContextType` and the corre
|
|||
----
|
||||
|
||||
|
||||
[[xsd-schemas-util-property-path]]
|
||||
[[core.appendix.xsd-schemas-util-property-path]]
|
||||
==== Using `<util:property-path/>`
|
||||
|
||||
Consider the following example:
|
||||
|
|
@ -227,7 +228,7 @@ The value of the `path` attribute of the `<property-path/>` element follows the
|
|||
`beanName.beanProperty`. In this case, it picks up the `age` property of the bean named
|
||||
`testBean`. The value of that `age` property is `10`.
|
||||
|
||||
[[xsd-schemas-util-property-path-dependency]]
|
||||
[[core.appendix.xsd-schemas-util-property-path-dependency]]
|
||||
===== Using `<util:property-path/>` to Set a Bean Property or Constructor Argument
|
||||
|
||||
`PropertyPathFactoryBean` is a `FactoryBean` that evaluates a property path on a given
|
||||
|
|
@ -302,7 +303,7 @@ for most use cases, but it can sometimes be useful. See the javadoc for more inf
|
|||
this feature.
|
||||
|
||||
|
||||
[[xsd-schemas-util-properties]]
|
||||
[[core.appendix.xsd-schemas-util-properties]]
|
||||
==== Using `<util:properties/>`
|
||||
|
||||
Consider the following example:
|
||||
|
|
@ -328,7 +329,7 @@ The following example uses a `util:properties` element to make a more concise re
|
|||
----
|
||||
|
||||
|
||||
[[xsd-schemas-util-list]]
|
||||
[[core.appendix.xsd-schemas-util-list]]
|
||||
==== Using `<util:list/>`
|
||||
|
||||
Consider the following example:
|
||||
|
|
@ -383,7 +384,7 @@ following configuration:
|
|||
If no `list-class` attribute is supplied, the container chooses a `List` implementation.
|
||||
|
||||
|
||||
[[xsd-schemas-util-map]]
|
||||
[[core.appendix.xsd-schemas-util-map]]
|
||||
==== Using `<util:map/>`
|
||||
|
||||
Consider the following example:
|
||||
|
|
@ -438,7 +439,7 @@ following configuration:
|
|||
If no `'map-class'` attribute is supplied, the container chooses a `Map` implementation.
|
||||
|
||||
|
||||
[[xsd-schemas-util-set]]
|
||||
[[core.appendix.xsd-schemas-util-set]]
|
||||
==== Using `<util:set/>`
|
||||
|
||||
Consider the following example:
|
||||
|
|
@ -494,7 +495,7 @@ If no `set-class` attribute is supplied, the container chooses a `Set` implement
|
|||
|
||||
|
||||
|
||||
[[xsd-schemas-aop]]
|
||||
[[core.appendix.xsd-schemas-aop]]
|
||||
=== The `aop` Schema
|
||||
|
||||
The `aop` tags deal with configuring all things AOP in Spring, including Spring's
|
||||
|
|
@ -524,7 +525,7 @@ are available to you):
|
|||
|
||||
|
||||
|
||||
[[xsd-schemas-context]]
|
||||
[[core.appendix.xsd-schemas-context]]
|
||||
=== The `context` Schema
|
||||
|
||||
The `context` tags deal with `ApplicationContext` configuration that relates to plumbing
|
||||
|
|
@ -549,7 +550,7 @@ available to you:
|
|||
----
|
||||
|
||||
|
||||
[[xsd-schemas-context-pphc]]
|
||||
[[core.appendix.xsd-schemas-context-pphc]]
|
||||
==== Using `<property-placeholder/>`
|
||||
|
||||
This element activates the replacement of `${...}` placeholders, which are resolved against a
|
||||
|
|
@ -559,7 +560,7 @@ is a convenience mechanism that sets up a <<core.adoc#beans-factory-placeholderc
|
|||
`PropertySourcesPlaceholderConfigurer` setup, you can explicitly define it as a bean yourself.
|
||||
|
||||
|
||||
[[xsd-schemas-context-ac]]
|
||||
[[core.appendix.xsd-schemas-context-ac]]
|
||||
==== Using `<annotation-config/>`
|
||||
|
||||
This element activates the Spring infrastructure to detect annotations in bean classes:
|
||||
|
|
@ -582,28 +583,28 @@ element for that purpose. Similarly, Spring's
|
|||
<<integration.adoc#cache-annotation-enable, enabled>> as well.
|
||||
|
||||
|
||||
[[xsd-schemas-context-component-scan]]
|
||||
[[core.appendix.xsd-schemas-context-component-scan]]
|
||||
==== Using `<component-scan/>`
|
||||
|
||||
This element is detailed in the section on <<core.adoc#beans-annotation-config,
|
||||
annotation-based container configuration>>.
|
||||
|
||||
|
||||
[[xsd-schemas-context-ltw]]
|
||||
[[core.appendix.xsd-schemas-context-ltw]]
|
||||
==== Using `<load-time-weaver/>`
|
||||
|
||||
This element is detailed in the section on <<core.adoc#aop-aj-ltw,
|
||||
load-time weaving with AspectJ in the Spring Framework>>.
|
||||
|
||||
|
||||
[[xsd-schemas-context-sc]]
|
||||
[[core.appendix.xsd-schemas-context-sc]]
|
||||
==== Using `<spring-configured/>`
|
||||
|
||||
This element is detailed in the section on <<core.adoc#aop-atconfigurable,
|
||||
using AspectJ to dependency inject domain objects with Spring>>.
|
||||
|
||||
|
||||
[[xsd-schemas-context-mbe]]
|
||||
[[core.appendix.xsd-schemas-context-mbe]]
|
||||
==== Using `<mbean-export/>`
|
||||
|
||||
This element is detailed in the section on <<integration.adoc#jmx-context-mbeanexport,
|
||||
|
|
@ -611,7 +612,7 @@ configuring annotation-based MBean export>>.
|
|||
|
||||
|
||||
|
||||
[[xsd-schemas-beans]]
|
||||
[[core.appendix.xsd-schemas-beans]]
|
||||
=== The Beans Schema
|
||||
|
||||
Last but not least, we have the elements in the `beans` schema. These elements
|
||||
|
|
@ -623,7 +624,7 @@ in <<core.adoc#beans-factory-properties-detailed, dependencies and configuration
|
|||
Note that you can add zero or more key-value pairs to `<bean/>` XML definitions.
|
||||
What, if anything, is done with this extra metadata is totally up to your own custom
|
||||
logic (and so is typically only of use if you write your own custom elements as described
|
||||
in the appendix entitled <<xml-custom>>).
|
||||
in the appendix entitled <<core.appendix.xml-custom>>).
|
||||
|
||||
The following example shows the `<meta/>` element in the context of a surrounding `<bean/>`
|
||||
(note that, without any logic to interpret it, the metadata is effectively useless
|
||||
|
|
@ -652,10 +653,10 @@ the bean definition and sets up some caching infrastructure that uses the suppli
|
|||
|
||||
|
||||
|
||||
[[xml-custom]]
|
||||
[[core.appendix.xml-custom]]
|
||||
== XML Schema Authoring
|
||||
|
||||
[[xsd-custom-introduction]]
|
||||
[[core.appendix.xsd-custom-introduction]]
|
||||
Since version 2.0, Spring has featured a mechanism for adding schema-based extensions to the
|
||||
basic Spring XML format for defining and configuring beans. This section covers
|
||||
how to write your own custom XML bean definition parsers and
|
||||
|
|
@ -664,16 +665,16 @@ integrate such parsers into the Spring IoC container.
|
|||
To facilitate authoring configuration files that use a schema-aware XML editor,
|
||||
Spring's extensible XML configuration mechanism is based on XML Schema. If you are not
|
||||
familiar with Spring's current XML configuration extensions that come with the standard
|
||||
Spring distribution, you should first read the previous section on <<xsd-schemas>>.
|
||||
Spring distribution, you should first read the previous section on <<core.appendix.xsd-schemas>>.
|
||||
|
||||
|
||||
To create new XML configuration extensions:
|
||||
|
||||
. <<xsd-custom-schema, Author>> an XML schema to describe your custom element(s).
|
||||
. <<xsd-custom-namespacehandler, Code>> a custom `NamespaceHandler` implementation.
|
||||
. <<xsd-custom-parser, Code>> one or more `BeanDefinitionParser` implementations
|
||||
. <<core.appendix.xsd-custom-schema, Author>> an XML schema to describe your custom element(s).
|
||||
. <<core.appendix.xsd-custom-namespacehandler, Code>> a custom `NamespaceHandler` implementation.
|
||||
. <<core.appendix.xsd-custom-parser, Code>> one or more `BeanDefinitionParser` implementations
|
||||
(this is where the real work is done).
|
||||
. <<xsd-custom-registration, Register>> your new artifacts with Spring.
|
||||
. <<core.appendix.xsd-custom-registration, Register>> your new artifacts with Spring.
|
||||
|
||||
For a unified example, we create an
|
||||
XML extension (a custom XML element) that lets us configure objects of the type
|
||||
|
|
@ -693,7 +694,7 @@ through the basic steps of making a custom extension.)
|
|||
|
||||
|
||||
|
||||
[[xsd-custom-schema]]
|
||||
[[core.appendix.xsd-custom-schema]]
|
||||
=== Authoring the Schema
|
||||
|
||||
Creating an XML configuration extension for use with Spring's IoC container starts with
|
||||
|
|
@ -765,7 +766,7 @@ defined in the enumeration.
|
|||
|
||||
|
||||
|
||||
[[xsd-custom-namespacehandler]]
|
||||
[[core.appendix.xsd-custom-namespacehandler]]
|
||||
=== Coding a `NamespaceHandler`
|
||||
|
||||
In addition to the schema, we need a `NamespaceHandler` to parse all elements of
|
||||
|
|
@ -836,7 +837,7 @@ custom element, as we can see in the next step.
|
|||
|
||||
|
||||
|
||||
[[xsd-custom-parser]]
|
||||
[[core.appendix.xsd-custom-parser]]
|
||||
=== Using `BeanDefinitionParser`
|
||||
|
||||
A `BeanDefinitionParser` is used if the `NamespaceHandler` encounters an XML
|
||||
|
|
@ -926,7 +927,7 @@ is the extraction and setting of the bean definition's unique identifier.
|
|||
|
||||
|
||||
|
||||
[[xsd-custom-registration]]
|
||||
[[core.appendix.xsd-custom-registration]]
|
||||
=== Registering the Handler and the Schema
|
||||
|
||||
The coding is finished. All that remains to be done is to make the Spring XML
|
||||
|
|
@ -938,7 +939,7 @@ XML parsing infrastructure automatically picks up your new extension by consumin
|
|||
these special properties files, the formats of which are detailed in the next two sections.
|
||||
|
||||
|
||||
[[xsd-custom-registration-spring-handlers]]
|
||||
[[core.appendix.xsd-custom-registration-spring-handlers]]
|
||||
==== Writing `META-INF/spring.handlers`
|
||||
|
||||
The properties file called `spring.handlers` contains a mapping of XML Schema URIs to
|
||||
|
|
@ -957,7 +958,7 @@ namespace extension and needs to exactly match exactly the value of the `targetN
|
|||
attribute, as specified in your custom XSD schema.
|
||||
|
||||
|
||||
[[xsd-custom-registration-spring-schemas]]
|
||||
[[core.appendix.xsd-custom-registration-spring-schemas]]
|
||||
==== Writing 'META-INF/spring.schemas'
|
||||
|
||||
The properties file called `spring.schemas` contains a mapping of XML Schema locations
|
||||
|
|
@ -981,7 +982,7 @@ the `NamespaceHandler` and `BeanDefinitionParser` classes on the classpath.
|
|||
|
||||
|
||||
|
||||
[[xsd-custom-using]]
|
||||
[[core.appendix.xsd-custom-using]]
|
||||
=== Using a Custom Extension in Your Spring XML Configuration
|
||||
|
||||
Using a custom extension that you yourself have implemented is no different from using
|
||||
|
|
@ -1015,13 +1016,13 @@ in a Spring XML configuration file:
|
|||
|
||||
|
||||
|
||||
[[xsd-custom-meat]]
|
||||
[[core.appendix.xsd-custom-meat]]
|
||||
=== More Detailed Examples
|
||||
|
||||
This section presents some more detailed examples of custom XML extensions.
|
||||
|
||||
|
||||
[[xsd-custom-custom-nested]]
|
||||
[[core.appendix.xsd-custom-custom-nested]]
|
||||
==== Nesting Custom Elements within Custom Elements
|
||||
|
||||
The example presented in this section shows how you to write the various artifacts required
|
||||
|
|
@ -1195,7 +1196,7 @@ setter property for the `components` property. The following listing shows such
|
|||
|
||||
This works nicely, but it exposes a lot of Spring plumbing to the end user. What we are
|
||||
going to do is write a custom extension that hides away all of this Spring plumbing.
|
||||
If we stick to <<xsd-custom-introduction, the steps described previously>>, we start off
|
||||
If we stick to <<core.appendix.xsd-custom-introduction, the steps described previously>>, we start off
|
||||
by creating the XSD schema to define the structure of our custom tag, as the following
|
||||
listing shows:
|
||||
|
||||
|
|
@ -1222,7 +1223,7 @@ listing shows:
|
|||
</xsd:schema>
|
||||
----
|
||||
|
||||
Again following <<xsd-custom-introduction, the process described earlier>>,
|
||||
Again following <<core.appendix.xsd-custom-introduction, the process described earlier>>,
|
||||
we then create a custom `NamespaceHandler`:
|
||||
|
||||
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
|
||||
|
|
@ -1373,7 +1374,7 @@ http\://www.foo.example/schema/component/component.xsd=com/foo/component.xsd
|
|||
----
|
||||
|
||||
|
||||
[[xsd-custom-custom-just-attributes]]
|
||||
[[core.appendix.xsd-custom-custom-just-attributes]]
|
||||
==== Custom Attributes on "`Normal`" Elements
|
||||
|
||||
Writing your own custom parser and the associated artifacts is not hard. However,
|
||||
|
|
@ -1610,7 +1611,7 @@ http\://www.foo.example/schema/jcache/jcache.xsd=com/foo/jcache.xsd
|
|||
----
|
||||
|
||||
|
||||
[[application-startup-steps]]
|
||||
[[core.appendix.application-startup-steps]]
|
||||
== Application Startup Steps
|
||||
|
||||
This part of the appendix lists the existing `StartupSteps` that the core container is instrumented with.
|
||||
|
|
|
|||
|
|
@ -1900,7 +1900,7 @@ The preceding configuration is equivalent to the following Java code:
|
|||
The p-namespace lets you use the `bean` element's attributes (instead of nested
|
||||
`<property/>` elements) to describe your property values collaborating beans, or both.
|
||||
|
||||
Spring supports extensible configuration formats <<core.adoc#xsd-schemas,with namespaces>>,
|
||||
Spring supports extensible configuration formats <<core.adoc#core.appendix.xsd-schemas,with namespaces>>,
|
||||
which are based on an XML Schema definition. The `beans` configuration format discussed in
|
||||
this chapter is defined in an XML Schema document. However, the p-namespace is not defined
|
||||
in an XSD file and exists only in the core of Spring.
|
||||
|
|
@ -3094,7 +3094,7 @@ understand the "`why`" as well as the "`how`" behind it:
|
|||
|
||||
To create such a proxy, you insert a child `<aop:scoped-proxy/>` element into a scoped
|
||||
bean definition (see <<beans-factory-scopes-other-injection-proxies>> and
|
||||
<<core.adoc#xsd-schemas, XML Schema-based configuration>>).
|
||||
<<core.adoc#core.appendix.xsd-schemas, XML Schema-based configuration>>).
|
||||
Why do definitions of beans scoped at the `request`, `session` and custom-scope
|
||||
levels require the `<aop:scoped-proxy/>` element?
|
||||
Consider the following singleton bean definition and contrast it with
|
||||
|
|
@ -10995,7 +10995,7 @@ Here is an example of instrumentation in the `AnnotationConfigApplicationContext
|
|||
The application context is already instrumented with multiple steps.
|
||||
Once recorded, these startup steps can be collected, displayed and analyzed with specific tools.
|
||||
For a complete list of existing startup steps, you can check out the
|
||||
<<application-startup-steps, dedicated appendix section>>.
|
||||
<<core.appendix.application-startup-steps, dedicated appendix section>>.
|
||||
|
||||
The default `ApplicationStartup` implementation is a no-op variant, for minimal overhead.
|
||||
This means no metrics will be collected during application startup by default.
|
||||
|
|
|
|||
|
|
@ -326,7 +326,7 @@ infrastructure.
|
|||
|
||||
NOTE: The preceding definition of the `dataSource` bean uses the `<jndi-lookup/>` tag
|
||||
from the `jee` namespace. For more information see
|
||||
<<integration.adoc#xsd-schemas-jee, The JEE Schema>>.
|
||||
<<integration.adoc#integration.appendix.xsd-schemas-jee, The JEE Schema>>.
|
||||
|
||||
NOTE: If you use JTA, your transaction manager definition should look the same, regardless
|
||||
of what data access technology you use, be it JDBC, Hibernate JPA, or any other supported
|
||||
|
|
|
|||
|
|
@ -1,9 +1,10 @@
|
|||
[[data.access.appendix]]
|
||||
= Appendix
|
||||
|
||||
|
||||
|
||||
|
||||
[[xsd-schemas]]
|
||||
[[data.access.xsd-schemas]]
|
||||
== XML Schemas
|
||||
|
||||
This part of the appendix lists XML schemas for data access, including the following:
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Email, Tasks, Scheduling, Caching.
|
|||
https://github.com/spring-projects/spring-framework/wiki[*Wiki*] :: What's New,
|
||||
Upgrade Notes, Supported Versions, and other cross-version information.
|
||||
|
||||
NOTE: This documentation is available in {docs-spring-framework}/reference/html/index.html[HTML] and {docs-spring-framework}/reference/pdf/index.pdf[PDF] formats.
|
||||
NOTE: This documentation is available in {docs-spring-framework}/reference/html/index.html[HTML] and {docs-spring-framework}/reference/pdf/spring-framework.pdf[PDF] formats.
|
||||
|
||||
Rod Johnson, Juergen Hoeller, Keith Donald, Colin Sampaleanu, Rob Harrop, Thomas Risberg,
|
||||
Alef Arendsen, Darren Davison, Dmitriy Kopylenko, Mark Pollack, Thierry Templier, Erwin
|
||||
|
|
|
|||
|
|
@ -1,16 +1,17 @@
|
|||
[[integration.appendix]]
|
||||
= Appendix
|
||||
|
||||
|
||||
|
||||
|
||||
[[xsd-schemas]]
|
||||
[[integration.appendix.xsd-schemas]]
|
||||
== XML Schemas
|
||||
|
||||
This part of the appendix lists XML schemas related to integration technologies.
|
||||
|
||||
|
||||
|
||||
[[xsd-schemas-jee]]
|
||||
[[integration.appendix.xsd-schemas-jee]]
|
||||
=== The `jee` Schema
|
||||
|
||||
The `jee` elements deal with issues related to Jakarta EE (Enterprise Edition) configuration,
|
||||
|
|
@ -37,7 +38,7 @@ correct schema so that the elements in the `jee` namespace are available to you:
|
|||
|
||||
|
||||
|
||||
[[xsd-schemas-jee-jndi-lookup]]
|
||||
[[integration.appendix.xsd-schemas-jee-jndi-lookup]]
|
||||
==== <jee:jndi-lookup/> (simple)
|
||||
|
||||
The following example shows how to use JNDI to look up a data source without the `jee` schema:
|
||||
|
|
@ -68,7 +69,7 @@ schema:
|
|||
|
||||
|
||||
|
||||
[[xsd-schemas-jee-jndi-lookup-environment-single]]
|
||||
[[integration.appendix.xsd-schemas-jee-jndi-lookup-environment-single]]
|
||||
==== `<jee:jndi-lookup/>` (with Single JNDI Environment Setting)
|
||||
|
||||
The following example shows how to use JNDI to look up an environment variable without
|
||||
|
|
@ -96,7 +97,7 @@ The following example shows how to use JNDI to look up an environment variable w
|
|||
----
|
||||
|
||||
|
||||
[[xsd-schemas-jee-jndi-lookup-environment-multiple]]
|
||||
[[integration.appendix.xsd-schemas-jee-jndi-lookup-environment-multiple]]
|
||||
==== `<jee:jndi-lookup/>` (with Multiple JNDI Environment Settings)
|
||||
|
||||
The following example shows how to use JNDI to look up multiple environment variables
|
||||
|
|
@ -130,7 +131,7 @@ The following example shows how to use JNDI to look up multiple environment vari
|
|||
----
|
||||
|
||||
|
||||
[[xsd-schemas-jee-jndi-lookup-complex]]
|
||||
[[integration.appendix.xsd-schemas-jee-jndi-lookup-complex]]
|
||||
==== `<jee:jndi-lookup/>` (Complex)
|
||||
|
||||
The following example shows how to use JNDI to look up a data source and a number of
|
||||
|
|
@ -164,7 +165,7 @@ different properties with `jee`:
|
|||
|
||||
|
||||
|
||||
[[xsd-schemas-jee-local-slsb]]
|
||||
[[integration.appendix.xsd-schemas-jee-local-slsb]]
|
||||
==== `<jee:local-slsb/>` (Simple)
|
||||
|
||||
The `<jee:local-slsb/>` element configures a reference to a local EJB Stateless Session Bean.
|
||||
|
|
@ -192,7 +193,7 @@ with `jee`:
|
|||
|
||||
|
||||
|
||||
[[xsd-schemas-jee-local-slsb-complex]]
|
||||
[[integration.appendix.xsd-schemas-jee-local-slsb-complex]]
|
||||
==== `<jee:local-slsb/>` (Complex)
|
||||
|
||||
The `<jee:local-slsb/>` element configures a reference to a local EJB Stateless Session Bean.
|
||||
|
|
@ -226,7 +227,7 @@ and a number of properties with `jee`:
|
|||
----
|
||||
|
||||
|
||||
[[xsd-schemas-jee-remote-slsb]]
|
||||
[[integration.appendix.xsd-schemas-jee-remote-slsb]]
|
||||
==== <jee:remote-slsb/>
|
||||
|
||||
The `<jee:remote-slsb/>` element configures a reference to a `remote` EJB Stateless Session Bean.
|
||||
|
|
@ -265,7 +266,7 @@ with `jee`:
|
|||
|
||||
|
||||
|
||||
[[xsd-schemas-jms]]
|
||||
[[integration.appendix.xsd-schemas-jms]]
|
||||
=== The `jms` Schema
|
||||
|
||||
The `jms` elements deal with configuring JMS-related beans, such as Spring's
|
||||
|
|
@ -296,7 +297,7 @@ are available to you:
|
|||
|
||||
|
||||
|
||||
[[xsd-schemas-context-mbe]]
|
||||
[[integration.appendix.xsd-schemas-context-mbe]]
|
||||
=== Using `<context:mbean-export/>`
|
||||
|
||||
This element is detailed in
|
||||
|
|
@ -304,7 +305,7 @@ This element is detailed in
|
|||
|
||||
|
||||
|
||||
[[xsd-schemas-cache]]
|
||||
[[integration.appendix.xsd-schemas-cache]]
|
||||
=== The `cache` Schema
|
||||
|
||||
You can use the `cache` elements to enable support for Spring's `@CacheEvict`, `@CachePut`,
|
||||
|
|
|
|||
|
|
@ -868,7 +868,7 @@ https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-featu
|
|||
|
||||
==== Constructor injection
|
||||
|
||||
As described in the <<testing#testcontext-junit-jupiter-di#spring-web-reactive, dedicated section>>,
|
||||
As described in the <<testing#testcontext-junit-jupiter-di, dedicated section>>,
|
||||
JUnit 5 allows constructor injection of beans which is pretty useful with Kotlin
|
||||
in order to use `val` instead of `lateinit var`. You can use
|
||||
{api-spring-framework}/test/context/TestConstructor.html[`@TestConstructor(autowireMode = AutowireMode.ALL)`]
|
||||
|
|
|
|||
|
|
@ -0,0 +1,25 @@
|
|||
:noheader:
|
||||
= Spring Framework Documentation
|
||||
|
||||
include::overview.adoc[leveloffset=+1]
|
||||
include::core.adoc[leveloffset=+1]
|
||||
include::testing.adoc[leveloffset=+1]
|
||||
include::data-access.adoc[leveloffset=+1]
|
||||
include::web.adoc[leveloffset=+1]
|
||||
include::web-reactive.adoc[leveloffset=+1]
|
||||
include::integration.adoc[leveloffset=+1]
|
||||
include::languages.adoc[leveloffset=+1]
|
||||
include::appendix.adoc[leveloffset=+1]
|
||||
|
||||
Rod Johnson, Juergen Hoeller, Keith Donald, Colin Sampaleanu, Rob Harrop, Thomas Risberg,
|
||||
Alef Arendsen, Darren Davison, Dmitriy Kopylenko, Mark Pollack, Thierry Templier, Erwin
|
||||
Vervaet, Portia Tung, Ben Hale, Adrian Colyer, John Lewis, Costin Leau, Mark Fisher, Sam
|
||||
Brannen, Ramnivas Laddad, Arjen Poutsma, Chris Beams, Tareq Abedrabbo, Andy Clement, Dave
|
||||
Syer, Oliver Gierke, Rossen Stoyanchev, Phillip Webb, Rob Winch, Brian Clozel, Stephane
|
||||
Nicoll, Sebastien Deleuze, Jay Bryant, Mark Paluch
|
||||
|
||||
Copyright © 2002 - 2022 VMware, Inc. All Rights Reserved.
|
||||
|
||||
Copies of this document may be made for your own use and for distribution to others,
|
||||
provided that you do not charge any fee for such copies and further provided that each
|
||||
copy contains this Copyright Notice, whether distributed in print or electronically.
|
||||
|
|
@ -214,7 +214,7 @@ Doing so lets you test things such as:
|
|||
The Spring Framework provides first-class support for integration testing in the
|
||||
`spring-test` module. The name of the actual JAR file might include the release version
|
||||
and might also be in the long `org.springframework.test` form, depending on where you get
|
||||
it from (see the <<core.adoc#dependency-management, section on Dependency Management>>
|
||||
it from (see the <<core.adoc#beans-dependencies, section on Dependency Management>>
|
||||
for an explanation). This library includes the `org.springframework.test` package, which
|
||||
contains valuable classes for integration testing with a Spring container. This testing
|
||||
does not rely on an application server or other deployment environment. Such tests are
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[web-uricomponents]]
|
||||
[id={chapter}.web-uricomponents]
|
||||
= UriComponents
|
||||
[.small]#Spring MVC and Spring WebFlux#
|
||||
|
||||
|
|
@ -101,12 +101,11 @@ You can shorten it further still with a full URI template, as the following exam
|
|||
|
||||
|
||||
|
||||
|
||||
[[web-uribuilder]]
|
||||
[id={chapter}.web-uribuilder]
|
||||
= UriBuilder
|
||||
[.small]#Spring MVC and Spring WebFlux#
|
||||
|
||||
<<web-uricomponents, `UriComponentsBuilder`>> implements `UriBuilder`. You can create a
|
||||
<<{chapter}.web-uricomponents, `UriComponentsBuilder`>> implements `UriBuilder`. You can create a
|
||||
`UriBuilder`, in turn, with a `UriBuilderFactory`. Together, `UriBuilderFactory` and
|
||||
`UriBuilder` provide a pluggable mechanism to build URIs from URI templates, based on
|
||||
shared configuration, such as a base URL, encoding preferences, and other details.
|
||||
|
|
@ -194,8 +193,7 @@ that holds configuration and preferences, as the following example shows:
|
|||
----
|
||||
|
||||
|
||||
|
||||
[[web-uri-encoding]]
|
||||
[id={chapter}.web-uri-encoding]
|
||||
= URI Encoding
|
||||
[.small]#Spring MVC and Spring WebFlux#
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
[[webflux]]
|
||||
:chapter: webflux
|
||||
= Spring WebFlux
|
||||
:doc-spring-security: {doc-root}/spring-security/reference
|
||||
|
||||
|
|
@ -1199,7 +1200,7 @@ instance. The `View` is then used to render the response.
|
|||
|
||||
[[webflux-viewresolution-handling]]
|
||||
==== Handling
|
||||
[.small]#<<web.adoc#mvc-handling, Web MVC>>#
|
||||
[.small]#<<web.adoc#mvc-viewresolver-handling, Web MVC>>#
|
||||
|
||||
The `HandlerResult` passed into `ViewResolutionResultHandler` contains the return value
|
||||
from the handler and the model that contains attributes added during request
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[testing]]
|
||||
[[webmvc.test]]
|
||||
= Testing
|
||||
[.small]#<<web-reactive.adoc#webflux-test, Same in Spring WebFlux>>#
|
||||
|
||||
|
|
|
|||
|
|
@ -622,7 +622,7 @@ through https://www.webjars.org/[WebJars].
|
|||
|
||||
[[mvc-view-script-integrate]]
|
||||
=== Script Templates
|
||||
[.small]#<<web-reactive.adoc#webflux-script-integrate, WebFlux>>#
|
||||
[.small]#<<web-reactive.adoc#webflux-view-script, WebFlux>>#
|
||||
|
||||
You can declare a `ScriptTemplateConfigurer` bean to specify the script engine to use,
|
||||
the script files to load, what function to call to render templates, and so on.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
[[mvc]]
|
||||
:chapter: mvc
|
||||
= Spring Web MVC
|
||||
:doc-spring-security: {doc-root}/spring-security/reference
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[websocket-intro]]
|
||||
[[{chapter}.websocket-intro]]
|
||||
= Introduction to WebSocket
|
||||
|
||||
The WebSocket protocol, https://tools.ietf.org/html/rfc6455[RFC 6455], provides a standardized
|
||||
|
|
@ -54,7 +54,7 @@ instructions of the cloud provider related to WebSocket support.
|
|||
|
||||
|
||||
|
||||
[[websocket-intro-architecture]]
|
||||
[[{chapter}.websocket-intro-architecture]]
|
||||
== HTTP Versus WebSocket
|
||||
|
||||
Even though WebSocket is designed to be HTTP-compatible and starts with an HTTP request,
|
||||
|
|
@ -80,7 +80,7 @@ In the absence of that, they need to come up with their own conventions.
|
|||
|
||||
|
||||
|
||||
[[websocket-intro-when-to-use]]
|
||||
[[{chapter}.websocket-intro-when-to-use]]
|
||||
== When to Use WebSockets
|
||||
|
||||
WebSockets can make a web page be dynamic and interactive. However, in many cases,
|
||||
|
|
|
|||
Loading…
Reference in New Issue