Stop referring to "Spring 3.x" features in documentation and code

This commit is contained in:
Sam Brannen 2023-01-20 11:44:34 +01:00
parent 8f94c4e933
commit 24f18275dd
39 changed files with 225 additions and 238 deletions

View File

@ -1100,12 +1100,15 @@ subclass is used to implement the Decorator pattern, weaving in the advice.
CGLIB proxying should generally be transparent to users. However, there are some issues
to consider:
* `Final` methods cannot be advised, as they cannot be overridden.
* There is no need to add CGLIB to your classpath. As of Spring 3.2, CGLIB is repackaged
and included in the spring-core JAR. In other words, CGLIB-based AOP works "`out of
the box`", as do JDK dynamic proxies.
* `final` classes cannot be proxied, because they cannot be extended.
* `final` methods cannot be advised, because they cannot be overridden.
* `private` methods cannot be advised, because they cannot be overridden.
There is little performance difference between CGLIB proxying and dynamic proxies.
NOTE: There is no need to add CGLIB to your classpath. CGLIB is repackaged and included
in the `spring-core` JAR. In other words, CGLIB-based AOP works "out of the box", as do
JDK dynamic proxies.
There is little performance difference between CGLIB proxies and dynamic proxies.
Performance should not be a decisive consideration in this case.

View File

@ -524,15 +524,13 @@ container that hosts the bean. A bean usually has only one identifier. However,
requires more than one, the extra ones can be considered aliases.
In XML-based configuration metadata, you use the `id` attribute, the `name` attribute, or
both to specify the bean identifiers. The `id` attribute lets you specify
exactly one id. Conventionally, these names are alphanumeric ('myBean',
'someService', etc.), but they can contain special characters as well. If you want to
introduce other aliases for the bean, you can also specify them in the `name`
attribute, separated by a comma (`,`), semicolon (`;`), or white space. As a
historical note, in versions prior to Spring 3.1, the `id` attribute was
defined as an `xsd:ID` type, which constrained possible characters. As of 3.1,
it is defined as an `xsd:string` type. Note that bean `id` uniqueness is still
enforced by the container, though no longer by XML parsers.
both to specify bean identifiers. The `id` attribute lets you specify exactly one `id`.
Conventionally, these names are alphanumeric ('myBean', 'someService', etc.), but they
can contain special characters as well. If you want to introduce other aliases for the
bean, you can also specify them in the `name` attribute, separated by a comma (`,`),
semicolon (`;`), or white space. Although the `id` attribute is defined as an
`xsd:string` type, bean `id` uniqueness is enforced by the container, though not by XML
parsers.
You are not required to supply a `name` or an `id` for a bean. If you do not supply a
`name` or `id` explicitly, the container generates a unique name for that bean. However,
@ -2704,8 +2702,8 @@ The following table describes the supported scopes:
the context of a web-aware Spring `ApplicationContext`.
|===
NOTE: As of Spring 3.0, a thread scope is available but is not registered by default. For
more information, see the documentation for
NOTE: A thread scope is available but is not registered by default. For more information,
see the documentation for
{api-spring-framework}/context/support/SimpleThreadScope.html[`SimpleThreadScope`].
For instructions on how to register this or any other custom scope, see
<<beans-factory-scopes-custom-using>>.
@ -4590,26 +4588,24 @@ configuration becomes decentralized and harder to control.
No matter the choice, Spring can accommodate both styles and even mix them together.
It is worth pointing out that through its <<beans-java, JavaConfig>> option, Spring lets
annotations be used in a non-invasive way, without touching the target components
source code and that, in terms of tooling, all configuration styles are supported by the
https://spring.io/tools[Spring Tools for Eclipse].
annotations be used in a non-invasive way, without touching the target components'
source code and that, in terms of tooling, all configuration styles are supported by
https://spring.io/tools[Spring Tools] for Eclipse, Visual Studio Code, and Theia.
****
An alternative to XML setup is provided by annotation-based configuration, which relies
on the bytecode metadata for wiring up components instead of angle-bracket declarations.
Instead of using XML to describe a bean wiring, the developer moves the configuration
into the component class itself by using annotations on the relevant class, method, or
field declaration. As mentioned in <<beans-factory-extension-bpp-examples-aabpp>>, using
a `BeanPostProcessor` in conjunction with annotations is a common means of extending the
Spring IoC container. For example, Spring 2.5 introduced an annotation-based approach to
drive Spring's dependency injection. Essentially, the <<beans-autowired-annotation,
`@Autowired`>> annotation provides the same capabilities as described in
<<beans-factory-autowire>> but with more fine-grained control and wider applicability.
Spring 2.5 also added support for JSR-250 annotations, such as `@PostConstruct` and
`@PreDestroy`. Spring 3.0 added support for JSR-330 (Dependency Injection for Java)
annotations contained in the `jakarta.inject` package such as `@Inject` and `@Named`.
Details about those annotations can be found in the <<beans-standard-annotations,
relevant section>>.
on bytecode metadata for wiring up components instead of XML declarations. Instead of
using XML to describe a bean wiring, the developer moves the configuration into the
component class itself by using annotations on the relevant class, method, or field
declaration. As mentioned in <<beans-factory-extension-bpp-examples-aabpp>>, using a
`BeanPostProcessor` in conjunction with annotations is a common means of extending the
Spring IoC container. For example, the <<beans-autowired-annotation, `@Autowired`>>
annotation provides the same capabilities as described in <<beans-factory-autowire>> but
with more fine-grained control and wider applicability. In addition, Spring provides
support for JSR-250 annotations, such as `@PostConstruct` and `@PreDestroy`, as well as
support for JSR-330 (Dependency Injection for Java) annotations contained in the
`jakarta.inject` package such as `@Inject` and `@Named`. Details about those annotations
can be found in the <<beans-standard-annotations, relevant section>>.
[NOTE]
====
@ -6237,7 +6233,7 @@ simply to be added to the application's classpath like any other library.
Most examples in this chapter use XML to specify the configuration metadata that produces
each `BeanDefinition` within the Spring container. The previous section
(<<beans-annotation-config>>) demonstrates how to provide a lot of the configuration
metadata through source-level annotations. Even in those examples, however, the "`base`"
metadata through source-level annotations. Even in those examples, however, the "base"
bean definitions are explicitly defined in the XML file, while the annotations drive only
the dependency injection. This section describes an option for implicitly detecting the
candidate components by scanning the classpath. Candidate components are classes that
@ -6249,10 +6245,9 @@ the container.
[NOTE]
====
Starting with Spring 3.0, many features provided by the Spring JavaConfig project are
part of the core Spring Framework. This allows you to define beans using Java rather
than using the traditional XML files. Take a look at the `@Configuration`, `@Bean`,
`@Import`, and `@DependsOn` annotations for examples of how to use these new features.
You can define beans using Java rather than using XML files. Take a look at the
`@Configuration`, `@Bean`, `@Import`, and `@DependsOn` annotations for examples of how to
use these features.
====
@ -7172,9 +7167,9 @@ arrangement (as though no index were present at all) by setting `spring.index.ig
[[beans-standard-annotations]]
== Using JSR 330 Standard Annotations
Starting with Spring 3.0, Spring offers support for JSR-330 standard annotations
(Dependency Injection). Those annotations are scanned in the same way as the Spring
annotations. To use them, you need to have the relevant jars in your classpath.
Spring offers support for JSR-330 standard annotations (Dependency Injection). Those
annotations are scanned in the same way as the Spring annotations. To use them, you need
to have the relevant jars in your classpath.
[NOTE]
=====
@ -8611,22 +8606,24 @@ about singletons here.
[NOTE]
====
As of Spring 3.2, it is no longer necessary to add CGLIB to your classpath because CGLIB
classes have been repackaged under `org.springframework.cglib` and included directly
within the spring-core JAR.
It is not necessary to add CGLIB to your classpath because CGLIB classes are repackaged
under the `org.springframework.cglib` package and included directly within the
`spring-core` JAR.
====
[TIP]
====
There are a few restrictions due to the fact that CGLIB dynamically adds features at
startup-time. In particular, configuration classes must not be final. However, as
of 4.3, any constructors are allowed on configuration classes, including the use of
`@Autowired` or a single non-default constructor declaration for default injection.
startup-time. In particular, configuration classes must not be final. However, any
constructors are allowed on configuration classes, including the use of `@Autowired` or a
single non-default constructor declaration for default injection.
If you prefer to avoid any CGLIB-imposed limitations, consider declaring your `@Bean`
methods on non-`@Configuration` classes (for example, on plain `@Component` classes instead).
Cross-method calls between `@Bean` methods are not then intercepted, so you have
to exclusively rely on dependency injection at the constructor or method level there.
methods on non-`@Configuration` classes (for example, on plain `@Component` classes
instead) or by annotating your configuration class with
`@Configuration(proxyBeanMethods = false)`. Cross-method calls between `@Bean` methods
are then not intercepted, so you have to exclusively rely on dependency injection at the
constructor or method level there.
====

View File

@ -2,7 +2,7 @@
= Validation, Data Binding, and Type Conversion
There are pros and cons for considering validation as business logic, and Spring offers
a design for validation (and data binding) that does not exclude either one of them.
a design for validation and data binding that does not exclude either one of them.
Specifically, validation should not be tied to the web tier and should be easy to localize,
and it should be possible to plug in any available validator. Considering these concerns,
Spring provides a `Validator` contract that is both basic and eminently usable
@ -15,18 +15,18 @@ provides the aptly named `DataBinder` to do exactly that. The `Validator` and th
limited to the web layer.
The `BeanWrapper` is a fundamental concept in the Spring Framework and is used in a lot
of places. However, you probably do not need to use the `BeanWrapper`
directly. Because this is reference documentation, however, we felt that some explanation
might be in order. We explain the `BeanWrapper` in this chapter, since, if you are
going to use it at all, you are most likely do so when trying to bind data to objects.
of places. However, you probably do not need to use the `BeanWrapper` directly. Because
this is reference documentation, however, we feel that some explanation might be in
order. We explain the `BeanWrapper` in this chapter, since, if you are going to use it at
all, you are most likely do so when trying to bind data to objects.
Spring's `DataBinder` and the lower-level `BeanWrapper` both use `PropertyEditorSupport`
implementations to parse and format property values. The `PropertyEditor` and
`PropertyEditorSupport` types are part of the JavaBeans specification and are also
explained in this chapter. Spring 3 introduced a `core.convert` package that provides a
general type conversion facility, as well as a higher-level "`format`" package for
formatting UI field values. You can use these packages as simpler alternatives to
`PropertyEditorSupport` implementations. They are also discussed in this chapter.
explained in this chapter. Spring's `core.convert` package provides a general type
conversion facility, as well as a higher-level `format` package for formatting UI field
values. You can use these packages as simpler alternatives to `PropertyEditorSupport`
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,
@ -861,12 +861,12 @@ as needed.
[[core-convert]]
== Spring Type Conversion
Spring 3 introduced a `core.convert` package that provides a general type conversion
system. The system defines an SPI to implement type conversion logic and an API
to perform type conversions at runtime. Within a Spring container, you can use this system
as an alternative to `PropertyEditor` implementations to convert externalized bean property value
strings to the required property types. You can also use the public API anywhere in your
application where type conversion is needed.
The `core.convert` package provides a general type conversion system. The system defines
an SPI to implement type conversion logic and an API to perform type conversions at
runtime. Within a Spring container, you can use this system as an alternative to
`PropertyEditor` implementations to convert externalized bean property value strings to
the required property types. You can also use the public API anywhere in your application
where type conversion is needed.
@ -1205,8 +1205,9 @@ web or desktop application. In such environments, you typically convert from `St
to support the client postback process, as well as back to `String` to support the
view rendering process. In addition, you often need to localize `String` values. The more
general `core.convert` `Converter` SPI does not address such formatting requirements
directly. To directly address them, Spring 3 introduced a convenient `Formatter` SPI that
provides a simple and robust alternative to `PropertyEditor` implementations for client environments.
directly. To directly address them, Spring provides a convenient `Formatter` SPI that
provides a simple and robust alternative to `PropertyEditor` implementations for client
environments.
In general, you can use the `Converter` SPI when you need to implement general-purpose type
conversion logic -- for example, for converting between a `java.util.Date` and a `Long`.
@ -1956,9 +1957,9 @@ javadoc for more information on these options.
[[validation-binder]]
=== Configuring a `DataBinder`
Since Spring 3, you can configure a `DataBinder` instance with a `Validator`. Once
configured, you can invoke the `Validator` by calling `binder.validate()`. Any validation
`Errors` are automatically added to the binder's `BindingResult`.
You can configure a `DataBinder` instance with a `Validator`. Once configured, you can
invoke the `Validator` by calling `binder.validate()`. Any validation `Errors` are
automatically added to the binder's `BindingResult`.
The following example shows how to use a `DataBinder` programmatically to invoke validation
logic after binding to a target object:

View File

@ -136,14 +136,16 @@ To configure the rules that the `TaskExecutor` uses, we expose simple bean prope
[[scheduling-task-scheduler]]
== The Spring `TaskScheduler` Abstraction
In addition to the `TaskExecutor` abstraction, Spring 3.0 introduced a `TaskScheduler`
with a variety of methods for scheduling tasks to run at some point in the future.
The following listing shows the `TaskScheduler` interface definition:
In addition to the `TaskExecutor` abstraction, Spring has a `TaskScheduler` SPI with a
variety of methods for scheduling tasks to run at some point in the future. The following
listing shows the `TaskScheduler` interface definition:
[source,java,indent=0,subs="verbatim,quotes"]
----
public interface TaskScheduler {
Clock getClock();
ScheduledFuture schedule(Runnable task, Trigger trigger);
ScheduledFuture schedule(Runnable task, Instant startTime);
@ -168,12 +170,11 @@ much more flexible.
[[scheduling-trigger-interface]]
=== `Trigger` Interface
The `Trigger` interface is essentially inspired by JSR-236 which, as of Spring 3.0,
was not yet officially implemented. The basic idea of the `Trigger` is that execution
times may be determined based on past execution outcomes or even arbitrary conditions.
If these determinations take into account the outcome of the preceding execution,
that information is available within a `TriggerContext`. The `Trigger` interface itself
is quite simple, as the following listing shows:
The `Trigger` interface is essentially inspired by JSR-236. The basic idea of the
`Trigger` is that execution times may be determined based on past execution outcomes or
even arbitrary conditions. If these determinations take into account the outcome of the
preceding execution, that information is available within a `TriggerContext`. The
`Trigger` interface itself is quite simple, as the following listing shows:
[source,java,indent=0,subs="verbatim,quotes"]
----
@ -192,6 +193,8 @@ default). The following listing shows the available methods for `Trigger` implem
----
public interface TriggerContext {
Clock getClock();
Instant lastScheduledExecution();
Instant lastActualExecution();

View File

@ -54,9 +54,9 @@ import org.springframework.util.ClassUtils;
* return type however, such exceptions cannot be transmitted back. In that case an
* {@link AsyncUncaughtExceptionHandler} can be registered to process such exceptions.
*
* <p>As of Spring 3.1.2 the {@code AnnotationAsyncExecutionInterceptor} subclass is
* preferred for use due to its support for executor qualification in conjunction with
* Spring's {@code @Async} annotation.
* <p>Note: the {@code AnnotationAsyncExecutionInterceptor} subclass is preferred
* due to its support for executor qualification in conjunction with Spring's
* {@code @Async} annotation.
*
* @author Juergen Hoeller
* @author Chris Beams
@ -71,8 +71,8 @@ public class AsyncExecutionInterceptor extends AsyncExecutionAspectSupport imple
/**
* Create a new instance with a default {@link AsyncUncaughtExceptionHandler}.
* @param defaultExecutor the {@link Executor} (typically a Spring {@link AsyncTaskExecutor}
* or {@link java.util.concurrent.ExecutorService}) to delegate to;
* as of 4.2.6, a local executor for this interceptor will be built otherwise
* or {@link java.util.concurrent.ExecutorService}) to delegate to; a local
* executor for this interceptor will be built otherwise
*/
public AsyncExecutionInterceptor(@Nullable Executor defaultExecutor) {
super(defaultExecutor);
@ -81,8 +81,8 @@ public class AsyncExecutionInterceptor extends AsyncExecutionAspectSupport imple
/**
* Create a new {@code AsyncExecutionInterceptor}.
* @param defaultExecutor the {@link Executor} (typically a Spring {@link AsyncTaskExecutor}
* or {@link java.util.concurrent.ExecutorService}) to delegate to;
* as of 4.2.6, a local executor for this interceptor will be built otherwise
* or {@link java.util.concurrent.ExecutorService}) to delegate to; a local
* executor for this interceptor will be built otherwise
* @param exceptionHandler the {@link AsyncUncaughtExceptionHandler} to use
*/
public AsyncExecutionInterceptor(@Nullable Executor defaultExecutor, AsyncUncaughtExceptionHandler exceptionHandler) {
@ -130,9 +130,12 @@ public class AsyncExecutionInterceptor extends AsyncExecutionAspectSupport imple
}
/**
* This implementation is a no-op for compatibility in Spring 3.1.2.
* Subclasses may override to provide support for extracting qualifier information,
* e.g. via an annotation on the given method.
* Get the qualifier for a specific executor to use when executing the given
* method.
* <p>The default implementation of this method is effectively a no-op.
* <p>Subclasses may override this method to provide support for extracting
* qualifier information &mdash; for example, via an annotation on the given
* method.
* @return always {@code null}
* @since 3.1.2
* @see #determineAsyncExecutor(Method)

View File

@ -34,7 +34,7 @@ import org.springframework.lang.Nullable;
public interface ConfigurablePropertyAccessor extends PropertyAccessor, PropertyEditorRegistry, TypeConverter {
/**
* Specify a Spring 3.0 ConversionService to use for converting
* Specify a {@link ConversionService} to use for converting
* property values, as an alternative to JavaBeans PropertyEditors.
*/
void setConversionService(@Nullable ConversionService conversionService);

View File

@ -184,8 +184,8 @@ public class MutablePropertyValues implements PropertyValues, Serializable {
/**
* Overloaded version of {@code addPropertyValue} that takes
* a property name and a property value.
* <p>Note: As of Spring 3.0, we recommend using the more concise
* and chaining-capable variant {@link #add}.
* <p>Note: we recommend using the more concise and chaining-capable variant
* {@link #add(String, Object)}.
* @param propertyName name of the property
* @param propertyValue value of the property
* @see #addPropertyValue(PropertyValue)

View File

@ -116,7 +116,7 @@ public class PropertyEditorRegistrySupport implements PropertyEditorRegistry {
/**
* Specify a Spring 3.0 ConversionService to use for converting
* Specify a {@link ConversionService} to use for converting
* property values, as an alternative to JavaBeans PropertyEditors.
*/
public void setConversionService(@Nullable ConversionService conversionService) {

View File

@ -147,7 +147,7 @@ public interface ConfigurableBeanFactory extends HierarchicalBeanFactory, Single
BeanExpressionResolver getBeanExpressionResolver();
/**
* Specify a Spring 3.0 ConversionService to use for converting
* Specify a {@link ConversionService} to use for converting
* property values, as an alternative to JavaBeans PropertyEditors.
* @since 3.0
*/

View File

@ -232,10 +232,10 @@ public abstract class PlaceholderConfigurerSupport extends PropertyResourceConfi
}
}
// New in Spring 2.5: resolve placeholders in alias target names and aliases as well.
// Resolve placeholders in alias target names and aliases as well.
beanFactoryToProcess.resolveAliases(valueResolver);
// New in Spring 3.0: resolve placeholders in embedded values such as annotation attributes.
// Resolve placeholders in embedded values such as annotation attributes.
beanFactoryToProcess.addEmbeddedValueResolver(valueResolver);
}

View File

@ -26,11 +26,11 @@ import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatException;
/**
* With Spring 3.1, bean id attributes (and all other id attributes across the
* core schemas) are no longer typed as xsd:id, but as xsd:string. This allows
* for using the same bean id within nested &lt;beans&gt; elements.
* Bean id attributes (and all other id attributes across the core schemas) are
* not typed as xsd:id, but as xsd:string. This allows for using the same bean
* id within nested &lt;beans&gt; elements.
*
* Duplicate ids *within the same level of nesting* will still be treated as an
* <p>Duplicate IDs *within the same level of nesting* will still be treated as an
* error through the ProblemReporter, as this could never be an intended/valid
* situation.
*

View File

@ -22,13 +22,13 @@ import java.util.function.Consumer;
/**
* Interface to be implemented by application event listeners.
*
* <p>Based on the standard {@code java.util.EventListener} interface
* for the Observer design pattern.
* <p>Based on the standard {@link java.util.EventListener} interface for the
* Observer design pattern.
*
* <p>As of Spring 3.0, an {@code ApplicationListener} can generically declare
* the event type that it is interested in. When registered with a Spring
* {@code ApplicationContext}, events will be filtered accordingly, with the
* listener getting invoked for matching event objects only.
* <p>An {@code ApplicationListener} can generically declare the event type that
* it is interested in. When registered with a Spring {@code ApplicationContext},
* events will be filtered accordingly, with the listener getting invoked for
* matching event objects only.
*
* @author Rod Johnson
* @author Juergen Hoeller

View File

@ -41,10 +41,9 @@ class PropertyPlaceholderBeanDefinitionParser extends AbstractPropertyLoadingBea
@Override
@SuppressWarnings("deprecation")
protected Class<?> getBeanClass(Element element) {
// As of Spring 3.1, the default value of system-properties-mode has changed from
// 'FALLBACK' to 'ENVIRONMENT'. This latter value indicates that resolution of
// placeholders against system properties is a function of the Environment and
// its current set of PropertySources.
// The default value of system-properties-mode is 'ENVIRONMENT'. This value
// indicates that resolution of placeholders against system properties is a
// function of the Environment and its current set of PropertySources.
if (SYSTEM_PROPERTIES_MODE_DEFAULT.equals(element.getAttribute(SYSTEM_PROPERTIES_MODE_ATTRIBUTE))) {
return PropertySourcesPlaceholderConfigurer.class;
}

View File

@ -26,13 +26,6 @@ import org.springframework.core.task.AsyncTaskExecutor;
* {@link Runnable Runnables} that match the exposed preferences
* of the {@code TaskExecutor} implementation in use.
*
* <p>Note: {@link SchedulingTaskExecutor} implementations are encouraged to also
* implement the {@link org.springframework.core.task.AsyncListenableTaskExecutor}
* interface. This is not required due to the dependency on Spring 4.0's
* {@link org.springframework.util.concurrent.ListenableFuture} interface,
* which would make it impossible for third-party executor implementations
* to remain compatible with both Spring 4.0 and Spring 3.x.
*
* @author Juergen Hoeller
* @since 2.0
* @see SchedulingAwareRunnable
@ -43,7 +36,7 @@ public interface SchedulingTaskExecutor extends AsyncTaskExecutor {
/**
* Does this {@code TaskExecutor} prefer short-lived tasks over long-lived tasks?
* <p>A {@code SchedulingTaskExecutor} implementation can indicate whether it
* prefers submitted tasks to perform as little work as they can within a single
* prefers submitted tasks to perform as little work as it can within a single
* task execution. For example, submitted tasks might break a repeated loop into
* individual subtasks which submit a follow-up task afterwards (if feasible).
* <p>This should be considered a hint. Of course {@code TaskExecutor} clients

View File

@ -26,9 +26,12 @@ import org.springframework.lang.Nullable;
/**
* Specialization of {@link AsyncExecutionInterceptor} that delegates method execution to
* an {@code Executor} based on the {@link Async} annotation. Specifically designed to
* support use of {@link Async#value()} executor qualification mechanism introduced in
* Spring 3.1.2. Supports detecting qualifier metadata via {@code @Async} at the method or
* an {@code Executor} based on the {@link Async} annotation.
*
* <p>Specifically designed to support use of the {@link Async#value()} executor
* qualifier mechanism.
*
* <p>Supports detecting qualifier metadata via {@code @Async} at the method or
* declaring class level. See {@link #getExecutorQualifier(Method)} for details.
*
* @author Chris Beams
@ -44,7 +47,7 @@ public class AnnotationAsyncExecutionInterceptor extends AsyncExecutionIntercept
* and a simple {@link AsyncUncaughtExceptionHandler}.
* @param defaultExecutor the executor to be used by default if no more specific
* executor has been qualified at the method level using {@link Async#value()};
* as of 4.2.6, a local executor for this interceptor will be built otherwise
* a local executor for this interceptor will be built otherwise
*/
public AnnotationAsyncExecutionInterceptor(@Nullable Executor defaultExecutor) {
super(defaultExecutor);
@ -54,7 +57,7 @@ public class AnnotationAsyncExecutionInterceptor extends AsyncExecutionIntercept
* Create a new {@code AnnotationAsyncExecutionInterceptor} with the given executor.
* @param defaultExecutor the executor to be used by default if no more specific
* executor has been qualified at the method level using {@link Async#value()};
* as of 4.2.6, a local executor for this interceptor will be built otherwise
* a local executor for this interceptor will be built otherwise
* @param exceptionHandler the {@link AsyncUncaughtExceptionHandler} to use to
* handle exceptions thrown by asynchronous method executions with {@code void}
* return type
@ -68,10 +71,10 @@ public class AnnotationAsyncExecutionInterceptor extends AsyncExecutionIntercept
* Return the qualifier or bean name of the executor to be used when executing the
* given method, specified via {@link Async#value} at the method or declaring
* class level. If {@code @Async} is specified at both the method and class level, the
* method's {@code #value} takes precedence (even if empty string, indicating that
* method's {@code value} takes precedence (even if empty string, indicating that
* the default executor should be used preferentially).
* @param method the method to inspect for executor qualifier metadata
* @return the qualifier if specified, otherwise empty string indicating that the
* @return the qualifier if specified, otherwise an empty string indicating that the
* {@linkplain #setExecutor(Executor) default executor} should be used
* @see #determineAsyncExecutor(Method)
*/

View File

@ -42,8 +42,8 @@ import org.springframework.util.CollectionUtils;
* Helper bean for registering tasks with a {@link TaskScheduler}, typically using cron
* expressions.
*
* <p>As of Spring 3.1, {@code ScheduledTaskRegistrar} has a more prominent user-facing
* role when used in conjunction with the {@link
* <p>{@code ScheduledTaskRegistrar} has a more prominent user-facing role when used in
* conjunction with the {@link
* org.springframework.scheduling.annotation.EnableAsync @EnableAsync} annotation and its
* {@link org.springframework.scheduling.annotation.SchedulingConfigurer
* SchedulingConfigurer} callback interface.

View File

@ -622,7 +622,7 @@ public class DataBinder implements PropertyEditorRegistry, TypeConverter {
//---------------------------------------------------------------------
/**
* Specify a Spring 3.0 ConversionService to use for converting
* Specify a {@link ConversionService} to use for converting
* property values, as an alternative to JavaBeans PropertyEditors.
*/
public void setConversionService(@Nullable ConversionService conversionService) {

View File

@ -43,12 +43,11 @@ package org.springframework.core.env;
* {@code Environment} in order to query profile state or resolve properties directly.
*
* <p>In most cases, however, application-level beans should not need to interact with the
* {@code Environment} directly but instead may have to have {@code ${...}} property
* {@code Environment} directly but instead may request to have {@code ${...}} property
* values replaced by a property placeholder configurer such as
* {@link org.springframework.context.support.PropertySourcesPlaceholderConfigurer
* PropertySourcesPlaceholderConfigurer}, which itself is {@code EnvironmentAware} and
* as of Spring 3.1 is registered by default when using
* {@code <context:property-placeholder/>}.
* registered by default when using {@code <context:property-placeholder/>}.
*
* <p>Configuration of the {@code Environment} object must be done through the
* {@code ConfigurableEnvironment} interface, returned from all

View File

@ -25,11 +25,11 @@ import java.util.concurrent.Executor;
* <p>Implementations can use all sorts of different execution strategies,
* such as: synchronous, asynchronous, using a thread pool, and more.
*
* <p>Equivalent to JDK 1.5's {@link java.util.concurrent.Executor}
* interface; extending it now in Spring 3.0, so that clients may declare
* a dependency on an Executor and receive any TaskExecutor implementation.
* This interface remains separate from the standard Executor interface
* mainly for backwards compatibility with JDK 1.4 in Spring 2.x.
* <p>Equivalent to Java's {@link java.util.concurrent.Executor} interface,
* so that clients may declare a dependency on an {@code Executor} and receive
* any {@code TaskExecutor} implementation. This interface remains separate from
* the standard {@code Executor} interface primarily for backwards compatibility
* with older APIs that depend on the {@code TaskExecutor} interface.
*
* @author Juergen Hoeller
* @since 2.0

View File

@ -22,13 +22,13 @@ import org.springframework.core.task.TaskExecutor;
import org.springframework.util.Assert;
/**
* Adapter that exposes the {@link java.util.concurrent.Executor} interface
* for any Spring {@link org.springframework.core.task.TaskExecutor}.
* Adapter that exposes the {@link java.util.concurrent.Executor} interface for
* any Spring {@link org.springframework.core.task.TaskExecutor}.
*
* <p>This is less useful as of Spring 3.0, since TaskExecutor itself
* extends the Executor interface. The adapter is only relevant for
* <em>hiding</em> the TaskExecutor nature of a given object now,
* solely exposing the standard Executor interface to a client.
* <p>This adapter is less useful since Spring 3.0, since TaskExecutor itself
* extends the {@code Executor} interface. The adapter is only relevant for
* <em>hiding</em> the {@code TaskExecutor} nature of a given object, solely
* exposing the standard {@code Executor} interface to a client.
*
* @author Juergen Hoeller
* @since 2.5

View File

@ -1265,17 +1265,17 @@ public abstract class ClassUtils {
/**
* Given a method, which may come from an interface, and a target class used
* in the current reflective invocation, find the corresponding target method
* if there is one. E.g. the method may be {@code IFoo.bar()} and the
* target class may be {@code DefaultFoo}. In this case, the method may be
* if there is one &mdash; for example, the method may be {@code IFoo.bar()},
* and the target class may be {@code DefaultFoo}. In this case, the method may be
* {@code DefaultFoo.bar()}. This enables attributes on that method to be found.
* <p><b>NOTE:</b> In contrast to {@link org.springframework.aop.support.AopUtils#getMostSpecificMethod},
* this method does <i>not</i> resolve bridge methods automatically.
* Call {@link org.springframework.core.BridgeMethodResolver#findBridgedMethod}
* if bridge method resolution is desirable (e.g. for obtaining metadata from
* the original method definition).
* <p><b>NOTE:</b> Since Spring 3.1.1, if Java security settings disallow reflective
* access (e.g. calls to {@code Class#getDeclaredMethods} etc, this implementation
* will fall back to returning the originally provided method.
* if bridge method resolution is desirable &mdash; for example, to obtain
* metadata from the original method definition.
* <p><b>NOTE:</b> If Java security settings disallow reflective access &mdash;
* for example, calls to {@code Class#getDeclaredMethods}, etc. &mdash; this
* implementation will fall back to returning the originally provided method.
* @param method the method to be invoked, which may come from an interface
* @param targetClass the target class for the current invocation
* (may be {@code null} or may not even implement the method)

View File

@ -43,17 +43,17 @@ import org.springframework.util.CollectionUtils;
* <p>Note: Since JDBC 4.0, it has been clarified that any methods using a String to identify
* the column should be using the column label. The column label is assigned using the ALIAS
* keyword in the SQL query string. When the query doesn't use an ALIAS, the default label is
* the column name. Most JDBC ResultSet implementations follow this new pattern but there are
* the column name. Most JDBC ResultSet implementations follow this pattern, but there are
* exceptions such as the {@code com.sun.rowset.CachedRowSetImpl} class which only uses
* the column name, ignoring any column labels. As of Spring 3.0.5, ResultSetWrappingSqlRowSet
* will translate column labels to the correct column index to provide better support for the
* the column name, ignoring any column labels. {@code ResultSetWrappingSqlRowSet}
* will translate column labels to the correct column index to provide better support for
* {@code com.sun.rowset.CachedRowSetImpl} which is the default implementation used by
* {@link org.springframework.jdbc.core.JdbcTemplate} when working with RowSets.
*
* <p>Note: This class implements the {@code java.io.Serializable} marker interface
* through the SqlRowSet interface, but is only actually serializable if the disconnected
* ResultSet/RowSet contained in it is serializable. Most CachedRowSet implementations
* are actually serializable, so this should usually work out.
* are actually serializable, so serialization should usually work.
*
* @author Thomas Risberg
* @author Juergen Hoeller
@ -78,7 +78,7 @@ public class ResultSetWrappingSqlRowSet implements SqlRowSet {
/**
* Create a new ResultSetWrappingSqlRowSet for the given ResultSet.
* Create a new {@code ResultSetWrappingSqlRowSet} for the given {@link ResultSet}.
* @param resultSet a disconnected ResultSet to wrap
* (usually a {@code javax.sql.rowset.CachedRowSet})
* @throws InvalidResultSetAccessException if extracting

View File

@ -2,7 +2,7 @@
* This package contains mock implementations of the
* {@link org.springframework.core.env.Environment Environment} and
* {@link org.springframework.core.env.PropertySource PropertySource}
* abstractions introduced in Spring 3.1.
* abstractions.
*
* <p>These <em>mocks</em> are useful for developing <em>out-of-container</em>
* unit tests for code that depends on environment-specific properties.

View File

@ -491,12 +491,12 @@ public class MockHttpServletResponse implements HttpServletResponse {
/**
* Return the primary value for the given header as a String, if any.
* Will return the first value in case of multiple values.
* <p>As of Servlet 3.0, this method is also defined in {@link HttpServletResponse}.
* As of Spring 3.1, it returns a stringified value for Servlet 3.0 compatibility.
* Consider using {@link #getHeaderValue(String)} for raw Object access.
* <p>Will return the first value in case of multiple values.
* <p>Returns a stringified value for Servlet 3.0 compatibility. Consider
* using {@link #getHeaderValue(String)} for raw Object access.
* @param name the name of the header
* @return the associated header value, or {@code null} if none
* @see HttpServletResponse#getHeader(String)
*/
@Override
@Nullable
@ -507,11 +507,11 @@ public class MockHttpServletResponse implements HttpServletResponse {
/**
* Return all values for the given header as a List of Strings.
* <p>As of Servlet 3.0, this method is also defined in {@link HttpServletResponse}.
* As of Spring 3.1, it returns a List of stringified values for Servlet 3.0 compatibility.
* <p>Returns a List of stringified values for Servlet 3.0 compatibility.
* Consider using {@link #getHeaderValues(String)} for raw Object access.
* @param name the name of the header
* @return the associated header values, or an empty List if none
* @see HttpServletResponse#getHeaders(String)
*/
@Override
public List<String> getHeaders(String name) {

View File

@ -34,17 +34,16 @@ import org.springframework.core.annotation.AliasFor;
*
* <h3>Supported Resource Types</h3>
*
* <p>Prior to Spring 3.1, only path-based resource locations (typically XML configuration
* files) were supported. As of Spring 3.1, {@linkplain #loader context loaders} may
* choose to support <em>either</em> path-based <em>or</em> class-based resources. As of
* Spring 4.0.4, {@linkplain #loader context loaders} may choose to support path-based
* <em>and</em> class-based resources simultaneously. Consequently
* <p>{@linkplain #loader Context loaders} may choose to support <em>either</em>
* path-based resource locations (typically XML configuration files) <em>or</em>
* class-based resources. Alternatively, context loaders may choose to support
* path-based <em>and</em> class-based resources simultaneously. Consequently
* {@code @ContextConfiguration} can be used to declare either path-based resource
* locations (via the {@link #locations} or {@link #value} attribute) <em>or</em>
* component classes (via the {@link #classes} attribute). Note, however, that most
* implementations of {@link SmartContextLoader} only support a single resource type. As
* of Spring 4.1, path-based resource locations may be either XML configuration files or
* Groovy scripts (if Groovy is on the classpath). Of course, third-party frameworks may
* implementations of {@link SmartContextLoader} only support a single resource type.
* Path-based resource locations may be either XML configuration files or Groovy
* scripts (if Groovy is on the classpath). Of course, third-party frameworks may
* choose to support additional types of path-based resources.
*
* <h3>Component Classes</h3>

View File

@ -49,9 +49,9 @@ import org.springframework.util.ResourceUtils;
* <em>Template Method</em> based approach for {@link #processLocations processing}
* resource locations.
*
* <p>As of Spring 3.1, {@code AbstractContextLoader} also provides a basis
* for all concrete implementations of the {@link SmartContextLoader} SPI. For
* backwards compatibility with the {@code ContextLoader} SPI,
* <p>{@code AbstractContextLoader} also provides a basis for all concrete implementations
* of the {@link SmartContextLoader} SPI. For backwards compatibility with the
* {@code ContextLoader} SPI,
* {@link #processContextConfiguration(ContextConfigurationAttributes)} delegates
* to {@link #processLocations(Class, String...)}.
*
@ -233,11 +233,11 @@ public abstract class AbstractContextLoader implements SmartContextLoader {
* is the value of the first configured
* {@linkplain #getResourceSuffixes() resource suffix} for which the
* generated location actually exists in the classpath.
* <p>As of Spring 3.1, the implementation of this method adheres to the
* contract defined in the {@link SmartContextLoader} SPI. Specifically,
* this method will <em>preemptively</em> verify that the generated default
* location actually exists. If it does not exist, this method will log a
* warning and return an empty array.
* <p>The implementation of this method adheres to the contract defined in the
* {@link SmartContextLoader} SPI. Specifically, this method will
* <em>preemptively</em> verify that the generated default location actually
* exists. If it does not exist, this method will log a warning and return an
* empty array.
* <p>Subclasses can override this method to implement a different
* <em>default location generation</em> strategy.
* @param clazz the class for which the default locations are to be generated
@ -294,13 +294,13 @@ public abstract class AbstractContextLoader implements SmartContextLoader {
* Determine whether <em>default</em> resource locations should be
* generated if the {@code locations} provided to
* {@link #processLocations(Class, String...)} are {@code null} or empty.
* <p>As of Spring 3.1, the semantics of this method have been overloaded
* to include detection of either default resource locations or default
* configuration classes. Consequently, this method can also be used to
* determine whether <em>default</em> configuration classes should be
* detected if the {@code classes} present in the
* {@link ContextConfigurationAttributes configuration attributes} supplied
* to {@link #processContextConfiguration(ContextConfigurationAttributes)}
* <p>The semantics of this method have been overloaded to include detection
* of either default resource locations or default configuration classes.
* Consequently, this method can also be used to determine whether
* <em>default</em> configuration classes should be detected if the
* {@code classes} present in the {@linkplain ContextConfigurationAttributes
* configuration attributes} supplied to
* {@link #processContextConfiguration(ContextConfigurationAttributes)}
* are {@code null} or empty.
* <p>Can be overridden by subclasses to change the default behavior.
* @return always {@code true} by default

View File

@ -60,8 +60,8 @@ import org.springframework.util.Assert;
* (e.g., XML configuration files and Groovy scripts) or annotated classes,
* but not both simultaneously.
*
* <p>As of Spring Framework 3.2, a test class may optionally declare neither path-based
* resource locations nor annotated classes and instead declare only {@linkplain
* <p>A test class may optionally declare neither path-based resource locations
* nor annotated classes and instead declare only {@linkplain
* ContextConfiguration#initializers application context initializers}. In such
* cases, an attempt will still be made to detect defaults, but their absence will
* not result in an exception.

View File

@ -23,12 +23,10 @@ import org.springframework.util.ResourceUtils;
* Extension of {@link SpringJUnit4ClassRunnerAppCtxTests}, which verifies that
* we can specify multiple resource locations for our application context, each
* configured differently.
* <p>
* As of Spring 3.0,
* {@code MultipleResourcesSpringJUnit4ClassRunnerAppCtxTests} is also used
* to verify support for the new {@code value} attribute alias for
*
* <p>{@code MultipleResourcesSpringJUnit4ClassRunnerAppCtxTests} is also used
* to verify support for the {@code value} attribute alias for
* {@code @ContextConfiguration}'s {@code locations} attribute.
* </p>
*
* @author Sam Brannen
* @since 2.5

View File

@ -70,10 +70,10 @@ import org.springframework.util.StringUtils;
* load or obtain and hook up a shared parent context to the root application context.
* See the {@link #loadParentContext(ServletContext)} method for more information.
*
* <p>As of Spring 3.1, {@code ContextLoader} supports injecting the root web
* application context via the {@link #ContextLoader(WebApplicationContext)}
* constructor, allowing for programmatic configuration in Servlet initializers.
* See {@link org.springframework.web.WebApplicationInitializer} for usage examples.
* <p>{@code ContextLoader} supports injecting the root web application context
* via the {@link #ContextLoader(WebApplicationContext)} constructor, allowing for
* programmatic configuration in Servlet initializers. See
* {@link org.springframework.web.WebApplicationInitializer} for usage examples.
*
* @author Juergen Hoeller
* @author Colin Sampaleanu

View File

@ -23,8 +23,8 @@ import jakarta.servlet.ServletContextListener;
* Bootstrap listener to start up and shut down Spring's root {@link WebApplicationContext}.
* Simply delegates to {@link ContextLoader} as well as to {@link ContextCleanupListener}.
*
* <p>As of Spring 3.1, {@code ContextLoaderListener} supports injecting the root web
* application context via the {@link #ContextLoaderListener(WebApplicationContext)}
* <p>{@code ContextLoaderListener} supports injecting the root web application
* context via the {@link #ContextLoaderListener(WebApplicationContext)}
* constructor, allowing for programmatic configuration in Servlet initializers.
* See {@link org.springframework.web.WebApplicationInitializer} for usage examples.
*

View File

@ -63,8 +63,8 @@ import org.springframework.web.context.ContextLoader;
* ContextLoader and/or "contextClass" init-param for FrameworkServlet must be set to
* the fully-qualified name of this class.
*
* <p>As of Spring 3.1, this class may also be directly instantiated and injected into
* Spring's {@code DispatcherServlet} or {@code ContextLoaderListener} when using the
* <p>This class may also be directly instantiated and injected into Spring's
* {@code DispatcherServlet} or {@code ContextLoaderListener} when using the
* {@link org.springframework.web.WebApplicationInitializer WebApplicationInitializer}
* code-based alternative to {@code web.xml}. See its Javadoc for details and usage examples.
*

View File

@ -33,9 +33,9 @@ import org.springframework.web.context.ServletContextAware;
* In a purely Spring-based web application, no such linking in of
* ServletContext attributes will be necessary.
*
* <p><b>NOTE:</b> As of Spring 3.0, you may also use the "contextAttributes" default
* bean which is of type Map, and dereference it using an "#{contextAttributes.myKey}"
* expression to access a specific attribute by name.
* <p><b>NOTE:</b> You may also use the "contextAttributes" default bean, which is
* of type Map, and dereference it using a "#{contextAttributes.myKey}" expression
* to access a specific attribute by name.
*
* @author Juergen Hoeller
* @since 1.1.4

View File

@ -28,8 +28,8 @@ import org.springframework.web.context.ServletContextAware;
* Exposes that ServletContext init parameter when used as bean reference,
* effectively making it available as named Spring bean instance.
*
* <p><b>NOTE:</b> As of Spring 3.0, you may also use the "contextParameters" default
* bean which is of type Map, and dereference it using an "#{contextParameters.myKey}"
* <p><b>NOTE:</b> You may also use the "contextParameters" default bean, which
* is of type Map, and dereference it using a "#{contextParameters.myKey}"
* expression to access a specific parameter by name.
*
* @author Juergen Hoeller

View File

@ -42,7 +42,7 @@ import org.springframework.web.context.support.WebApplicationContextUtils;
* be delegated to that bean in the Spring context, which is required to implement
* the standard Servlet Filter interface.
*
* <p>This approach is particularly useful for Filter implementation with complex
* <p>This approach is particularly useful for Filter implementations with complex
* setup needs, allowing to apply the full Spring bean definition machinery to
* Filter instances. Alternatively, consider standard Filter setup in combination
* with looking up service beans from the Spring root application context.
@ -51,12 +51,13 @@ import org.springframework.web.context.support.WebApplicationContextUtils;
* will by default <i>not</i> be delegated to the target bean, relying on the
* Spring application context to manage the lifecycle of that bean. Specifying
* the "targetFilterLifecycle" filter init-param as "true" will enforce invocation
* of the {@code Filter.init} and {@code Filter.destroy} lifecycle methods
* on the target bean, letting the servlet container manage the filter lifecycle.
* of the {@link Filter#init(jakarta.servlet.FilterConfig)} and
* {@link Filter#destroy()} lifecycle methods on the target bean, letting the
* Servlet container manage the filter lifecycle.
*
* <p>As of Spring 3.1, {@code DelegatingFilterProxy} has been updated to optionally
* accept constructor parameters when using a Servlet container's instance-based filter
* registration methods, usually in conjunction with Spring's
* <p>{@code DelegatingFilterProxy} can optionally accept constructor parameters
* when using a Servlet container's instance-based filter registration methods,
* usually in conjunction with Spring's
* {@link org.springframework.web.WebApplicationInitializer} SPI. These constructors allow
* for providing the delegate Filter bean directly, or providing the application context
* and bean name to fetch, avoiding the need to look up the application context from the

View File

@ -22,23 +22,11 @@ import org.springframework.core.NestedExceptionUtils;
import org.springframework.lang.Nullable;
/**
* Subclass of {@link ServletException} that properly handles a root cause in terms
* of message and stacktrace, just like NestedChecked/RuntimeException does.
*
* <p>Note that the plain ServletException doesn't expose its root cause at all,
* neither in the exception message nor in printed stack traces! While this might
* be fixed in later Servlet API variants (which even differ per vendor for the
* same API version), it is not reliably available on Servlet 2.4 (the minimum
* version required by Spring 3.x), which is why we need to do it ourselves.
*
* <p>The similarity between this class and the NestedChecked/RuntimeException
* class is unavoidable, as this class needs to derive from ServletException.
* Legacy subclass of {@link ServletException} that handles a root cause in terms
* of message and stacktrace.
*
* @author Juergen Hoeller
* @since 1.2.5
* @see #getMessage
* @see org.springframework.core.NestedCheckedException
* @see org.springframework.core.NestedRuntimeException
* @deprecated as of 6.0, in favor of standard {@link ServletException} nesting
*/
@Deprecated(since = "6.0")

View File

@ -29,7 +29,7 @@ import static org.assertj.core.api.Assertions.assertThatExceptionOfType;
/**
* Tests the interaction between a WebApplicationContext and ContextLoaderListener with
* regard to config location precedence, overriding and defaulting in programmatic
* configuration use cases, e.g. with Spring 3.1's WebApplicationInitializer.
* configuration use cases, e.g. with WebApplicationInitializer.
*
* @author Chris Beams
* @since 3.1

View File

@ -424,7 +424,7 @@ public class MockHttpServletResponse implements HttpServletResponse {
buf.append("; Domain=").append(cookie.getDomain());
}
int maxAge = cookie.getMaxAge();
ZonedDateTime expires = (cookie instanceof MockCookie mockCookie? mockCookie.getExpires() : null);
ZonedDateTime expires = (cookie instanceof MockCookie mockCookie ? mockCookie.getExpires() : null);
if (maxAge >= 0) {
buf.append("; Max-Age=").append(maxAge);
buf.append("; Expires=");
@ -491,12 +491,12 @@ public class MockHttpServletResponse implements HttpServletResponse {
/**
* Return the primary value for the given header as a String, if any.
* Will return the first value in case of multiple values.
* <p>As of Servlet 3.0, this method is also defined in {@link HttpServletResponse}.
* As of Spring 3.1, it returns a stringified value for Servlet 3.0 compatibility.
* Consider using {@link #getHeaderValue(String)} for raw Object access.
* <p>Will return the first value in case of multiple values.
* <p>Returns a stringified value for Servlet 3.0 compatibility. Consider
* using {@link #getHeaderValue(String)} for raw Object access.
* @param name the name of the header
* @return the associated header value, or {@code null} if none
* @see HttpServletResponse#getHeader(String)
*/
@Override
@Nullable
@ -507,11 +507,11 @@ public class MockHttpServletResponse implements HttpServletResponse {
/**
* Return all values for the given header as a List of Strings.
* <p>As of Servlet 3.0, this method is also defined in {@link HttpServletResponse}.
* As of Spring 3.1, it returns a List of stringified values for Servlet 3.0 compatibility.
* <p>Returns a List of stringified values for Servlet 3.0 compatibility.
* Consider using {@link #getHeaderValues(String)} for raw Object access.
* @param name the name of the header
* @return the associated header values, or an empty List if none
* @see HttpServletResponse#getHeaders(String)
*/
@Override
public List<String> getHeaders(String name) {

View File

@ -145,9 +145,9 @@ import org.springframework.web.util.WebUtils;
* with mappings, handlers, etc. Only the root application context as loaded by
* {@link org.springframework.web.context.ContextLoaderListener}, if any, will be shared.
*
* <p>As of Spring 3.1, {@code DispatcherServlet} may now be injected with a web
* application context, rather than creating its own internally. This is useful in Servlet
* 3.0+ environments, which support programmatic registration of servlet instances.
* <p>{@code DispatcherServlet} may be injected with a web application context,
* rather than creating its own internally. This is useful in Servlet 3.0+
* environments, which support programmatic registration of servlet instances.
* See the {@link #DispatcherServlet(WebApplicationContext)} javadoc for details.
*
* @author Rod Johnson

View File

@ -123,9 +123,9 @@ import org.springframework.web.util.WebUtils;
* with XmlWebApplicationContext). The namespace can also be set explicitly via
* the "namespace" servlet init-param.
*
* <p>As of Spring 3.1, {@code FrameworkServlet} may now be injected with a web
* application context, rather than creating its own internally. This is useful in Servlet
* 3.0+ environments, which support programmatic registration of servlet instances. See
* <p>{@code FrameworkServlet} may be injected with a web application context,
* rather than creating its own internally. This is useful in Servlet 3.0+
* environments, which support programmatic registration of servlet instances. See
* {@link #FrameworkServlet(WebApplicationContext)} Javadoc for details.
*
* @author Rod Johnson