This commit introduces LocaleContextResolver interface, which is used
at ServerWebExchange level to resolve Locale, TimeZone and other i18n
related informations.
It follows Spring MVC locale resolution patterns with a few differences:
- Only LocaleContextResolver is supported since LocaleResolver is less
flexible
- Support is implemented in the org.springframework.web.server.i18n
package of spring-web module rather than in spring-webflux in order
to be able to leverage it at ServerWebExchange level
2 implementations are provided:
- FixedLocaleContextResolver
- AcceptHeaderLocaleContextResolver
It can be configured with both functional or annotation-based APIs.
Issue: SPR-15036
Previously `HandlerMapping` implementation were heavily relying on
`String` path patterns, `PathMatcher` implementations and dedicated maps
for matching incoming request URL to an actual request handler.
This commit adds the `PathPatternRegistry` that holds `PathPattern`
instances and the associated request handler — matching results are then
shared as `PathMatchResult` instances. `AbstractUrlHandlerMapping` will
use this registry directly, but other components dealing with request
matching (like `PatternsRequestCondition`) will directly use ordered
`PathPattern` collections since ordering is important there.
This opens the door for faster request matching and simplifies the
design of this part.
Issue: SPR-15608
This commit enables trailing slash matching in `PathPatternParser` by
default - this mirrors the default configuration in `PathMatcher`
implementations in MVC.
This commit removes the headers(HttpHeaders) method on ClientRequest and
ServerResponse, in favor of headers(Consumer<HttpHeaders>), which is
more flexible.
This commit improves the capacity calculation for the DefaultDataBuffer,
so that the capacity typically doubles instead of improving by the
minimal required amount.
Issue: SPR-15647
The revised builder emphasizes creating a list of resolvers either
built-in or custom with each top-level builder method resulting in
adding a resolver.
By default only the Header resolver is configured.
The path extension resolver is removed altogether to discourage its use
but is trivial to create manually with the helpf of
UriUtils#extractFileExtension + MediaTypeFactory.
Issue: SPR-15639
After the removal of suffix pattern matches, there is no longer a need
to expose the list of registered file extensions.
Also polish, refactor, and simplify the abstract base class
AbstractMappingContentTypeResolver and its sub-classes.
Issue: SPR-15639
There is no need for ResourceWebHandler to go through the
PathExtensionContentTypeResolver when MediaTypeFactory makes it easy to
perform such lookups for a given Resource.
This does not support any extensions explicitly registered through a
WebFluxConfigurer but it would be easy enough to pass those into
ResourceWebHandler as a simple Map<String, MediaType>, should the need
arise.
Issue: SPR-15639
The use of the undecoded URL path by default and the removal of suffix
pattern matching effectively means HttpRequestPathHelper is no longer
needed.
Issue: SPR-15640, SPR-15639
Introduce pathWithinApplication() in ServerHttpRequest and use it for
request mapping purposes instead of LookupPath.
In turn this means that for request mapping purposes:
1) the path is not decoded
2) suffix pattern matching is not supported
Issue: SPR-15640
Before this commit there was no special handling for URL encoding
of the path pattern string coming into the path pattern parser. No
assumptions were made about it being in an encoded form or not.
With this change it is assumed incoming path patterns are not
encoded and as part of parsing the parser builds PathPattern
objects that include encoded elements. For example parsing "/f o"
will create a path pattern of the form "/f%20o". In this form
it can then be used to match against encoded paths.
Handling encoded characters is not trivial and has resulted in
some loss in matching speed but care has been taken to
avoid unnecessary creation of additional heap objects. When
matching variables the variable values are return in a
decoded form. It is hoped the speed can be recovered, at least
for the common case of non-encoded incoming paths.
Issue: SPR-15640
This commit changes the use of `ResolvableType` to
`ParameterizedTypeReference` in all public-facing WebFlux APIs. This
change removes the necessity for providing the parameterized type
information twice: once for creating the `ResolvableType`, and once for
specifying a `BodyExtractor`.
Issue: SPR-15636
Avoid importing Kotlin 1.0.x from Mockito Kotlin and only depends on
kotlin-stdlib instead of kotlin-stdlib-jre8 since we don't use
additional jre7 or jre8 API.
This commit also removes nullability from two common spots: ResolvableType.getType() and TargetSource.getTarget(), both of which are never effectively null with any regular implementation. For such scenarios, a non-null empty type/target is the cleaner contract.
Issue: SPR-15540
This commit adds two Consumer based methods to ClientRequest that allow
for direct manipulation of the underlying headers or cookies map. As
such, these methods can be used to override or remove existing entries.
Issue: SPR-15635
Update AnnotationUtils to restore support for `null` arguments in
certain methods. Some existing upstream projects were relying on this
behavior.
Issue: SPR-15642
This commit changes the `headers(HttpHeaders)` method in
DefaultClientRequestBuilder so that it copies the individual header
values instead of using the `List<String>` value directly. The reason
for this change is that the list of values can be immutable, and adding
additional values after that could result in
UnsupportedOperationExceptions.
Beyond just formally declaring the current behavior, this revision actually enforces non-null behavior in selected signatures now, not tolerating null values anymore when not explicitly documented. It also changes some utility methods with historic null-in/null-out tolerance towards enforced non-null return values, making them a proper citizen in non-null assignments.
Some issues are left as to-do: in particular a thorough revision of spring-test, and a few tests with unclear failures (ignored as "TODO: NULLABLE") to be sorted out in a follow-up commit.
Issue: SPR-15540
Without this change the comparator thinks "/{foo}"
is more specific than "/{foo}.*". The minimal fix here
to address it is to copy what the AntPathMatcher
comparator does which is to consider '.*' as *not*
a usage of a wildcard. See PatternInfo#initCounters()
for the AntPathMatcher handling of this.
This change ensures the PathPattern comparator now produces
the expected result but suffix usage in general needs more
thought at some point.
Issue: SPR-15597
Restore matrix variable parsing code not resorting to the use of
WebUtils which brings Servlet API dependencies with it.
Instead the parsing logic is now exposed through HttpRequestPathHelper
which already contained the decoding logic and also the knowledge of
whether to decode the parsed variables or not.
Issue: SPR-15397
This commit adds the `LookupPath` class that contains the full
request path relative to the web context; the application can
get from it various information, including the file extension
and path parameters (if any).
Since that operation is done multiple times for each request, this
object is stored as an attribute at the `ServerWebExchange` level.
Issue: SPR-15397
With the new `ParsingPathMatcher` implementation, new patterns are now
allowed, such as `"/foo/{*bar}". The `"{*bar}"` segment will capture
everything until the end of the given path. Adding other elements after
that segment is illegal and will throw exceptions.
One can configure on a `PathMatchConfigurer` various options like
`useTrailingSlashMatch` and `useSuffixPatternMatch`; those options, when
enabled, will try to append suffixes like `".*"` and `"/"` to existing
path patterns. In case of a "capture the rest" pattern segment, those
options won't be honored.
This is why this commit ensures that an exception is thrown at the start
of the application if an illegal configuration is applied to the
`PathMatchConfigurer`.
Issue: SPR-15303, SPR-15558
When an exception happens while writing/flushing, the exception handling
for Servlet 3.1 based implementation will happen when
WriteListener#onError and AsyncListener#onError events are received
When reading more that once for a given request, the position/limit of
the buffer provided by Undertow should be reset in order to use the
full capacity of the buffer.
This commit fixes the implementation of
ExtractingResponseErrorHandler.hasError to allow for null values,
indicating an override of the behavior inherited from
DefaultResponseErrorHandler.
Issue: SPR-15544
Defining nullability of some API like EnvironmentCapable
or ConditionContext causes issues in Spring Boot because
in the context where they are used, it is known for sure
they will return non-null values even if their API can in
other context return null values.
It is better in this case for both Java and Kotlin to
not define at all the nullabity of such API.
In practice, this is achieved by removing the package level
@NonNullApi annotation and adding it only on the
relevant classes.
Issue: SPR-15540
The change to "optimize" the template by not rebuilding the reply
message when the original header channels was null was incorrect.
We need to null out those headers if they were originally null.
Issue: SPR-15991
This commit makes Spring @Nullable annotation leveraging
JSR 305 @TypeQualifierNickname + @Nonnull(when= When.MAYBE)
instead of directly using @javax.annotation.Nullable which
seems not designed to be used as a meta-annotation.
It also removes @TypeQualifierDefault since the purpose of
this annotation when applied at method level is to only
change return value nullability, not parameters one.
Issue: SPR-15540
This commit replaces the UnaryOperatory<ServerWebExchange> inputs with
Function<ServerWebExchange, ServerWebExchange> instead. Unfortunately
the composability methods inherited from Function don't work in terms
of generics for composing multiple UnaryOperator's.
Issue: SPR-15599
Provide a mechanism to override the configured send and receive
timeouts in the GenericMessagingTemplate.
- overload `doReceive()` to take a receive timeout argument
- for `sendAndReceive()` methods examine message headers for these
timeout values
- remove headers to avoid propagation
- avoid the unconditional rebuild of the reply message if the
original headers weren't present
- also remove headers from simple `send()` operations
- change javadocs for the setters to indicate they are now defaults
- add properties to allow the user to override the header names used
- change `TemporaryReplyChannel` to use `send` arg and change to static
- add package-protected ctor to avoid the compiler creating a
synthetic constructor for access
Issue: SPR-15591
This commit introduces ExtractingResponseErrorHandler: an alternative
ResponseErrorHandler that uses `HttpMessageConverter`s to convert HTTP
error responses to `RestClientException`.
Issue: SPR-15544
Simplify the internals of the DefaultCodecs implementation favoring
explicit fields per override vs a generic list of readers and writers
for overrides.
This commit introduces 2 new @Nullable and @NonNullApi
annotations that leverage JSR 305 (dormant but available via
Findbugs jsr305 dependency and already used by libraries
like OkHttp) meta-annotations to specify explicitly
null-safety of Spring Framework parameters and return values.
In order to avoid adding too much annotations, the
default is set at package level with @NonNullApi and
@Nullable annotations are added when needed at parameter or
return value level. These annotations are intended to be used
on Spring Framework itself but also by other Spring projects.
@Nullable annotations have been introduced based on Javadoc
and search of patterns like "return null;". It is expected that
nullability of Spring Framework API will be polished with
complementary commits.
In practice, this will make the whole Spring Framework API
null-safe for Kotlin projects (when KT-10942 will be fixed)
since Kotlin will be able to leverage these annotations to
know if a parameter or a return value is nullable or not. But
this is also useful for Java developers as well since IntelliJ
IDEA, for example, also understands these annotations to
generate warnings when unsafe nullable usages are detected.
Issue: SPR-15540
As a follow-up to the recent commit 246e72 some slight modifications
to MockServerExchangeMutator (renamed to ExchnageMutatorWebFilter).
Aside from the name change, the main difference is that "per request"
exchange processors are now simply applied via WebTestClient#filter(..).
Issue: SPR-15570
This commit also changes "hibval5Version" to the more general "hibvalVersion" build variable, and includes dependency updates to Caffeine 2.5.1 and JRuby 9.1.9.
Issue: SPR-13482
This commit replaces the option to bind the WebTestClient to an
HttpHandler to bind to a WebHandler instead.
This allows testing below the WebFlux level such as WebFilter,
WebHandler, or WebSession scenarios, but still a level above
HttpHandler so that WebTestClient is in charge of creating the
ServerWebExchange and expose consistently the
WebTestClient#MockServerSpec setup across all "mock" server bindToXxx
options.
Issue: SPR-15570
This commit factors ServerWebExchange mutator support out of
WebTestClient in favor of an independent public class called
MockServerExchangeMutator which implements WebFilter and can be
applied to the WebTestClient as any other WebFilter.
The MockServerExchangeMutator also exposes a method to apply
a client-side filter for "per request" mutators. See the Javadoc
of the MockServerExchangeMutator.
Issue: SPR-15570
This commit introduces a new method in HttpRequest:
`String getMethodValue`, which returns the HTTP method as a String.
Furthermore, HttpRequest.getMethod() has been given a default
implementation using this String value in combination with
`HttpMethod.resolve`.
Issue: SPR-15545
This commit changes all methods that return `Supplier<Stream<T>` to
return `List<T>` instead. This includes the HandlerStrategies, but also
BodyInserter.Context, BodyExtractor.Context, and ServerResponse.Context.
The reason for this change is that most of the strategies have some sort
of order, where more specific message readers - for instance - come
before generic ones. Such an ordering can only be enforced through a
List.
Issue: SPR-15578
This commit removes the RouterFunctions.toHandlerMapping method, in
favor of native support for RouterFunctions in @EnableWebFlux
configuration classes.
In order to accomplish this, the HandlerStrategies components has been
repurposed to only be used for the "bare-bones" HttpHandler, while the
(newly introduced) RouterFunctionMapping uses the strategies as exposed
through WebFluxConfigurationSupport.
Furthermore, this commit also introduces support for testing
RouterFunctions without resorting to an application context.
Issue: SPR-15536
Prior to this commit, resolving resources from webjars using the
`WebJarAssetLocator.getFullPath` could lead to multiple candidates,
since this method is trying to find *any* resource matching that path
under the given webjar location.
This commit replaces that call with
`WebJarAssetLocator.getFullPathExact`, which avoids those multiple
matches and only resolves resources if the given path is exact.
Issue: SPR-15526
(cherry picked from commit e2aa117ff9)
Prior to this commit, the AbstractFlashMapManager has used the
originating URI but the query string of the forwarded request. That
resulted to FlashMap not being matched even when both originating
URI and query string matched the FlashMap attributes. The originating
query string is now used to match the forwarded request.
Issue: SPR-15505
This commit adds support for configuring `WebFilter` and
`WebExceptionHandler` instances in HandlerStrategies. It also drops the
"native" support for `ResponseStatusException`s, in favor of the
`ResponseStatusExceptionHandler`, which is registered by default.
Issue: SPR-15518
The ResourceHandlerFunction now returns an `EntityResponse<Resource>`
(instead of a `ServerResponse`), so that filters can inspect/change the
returned Resource.
HttpMessageConverter's are client and server and arguably shouldn't
contain a server-side concept such a response status.
The status field is recent, it was added to differentiate 400 vs 500
errors with Jackson 2.9+ but there is no need for it since the same
distinction is reflected in raising an HttpMessageNotReadableException
vs a general HttpMessageConversionException.
Issue: SPR-15516
Starting with removing a package cycle on the use of
ResponseStatusException in the codec package, this commit generally
refines codec exception handling.
The new [Encoding|Decoding]Exception mirror the existing
HttpMessageNot[Readable|Writable]Exception and are used similarly
especially to differentiate betwen 400 and 500 errors when parsing
server request body content.
The commit also aligns some of the exception handling of JSON and XML
on the WebFlux side with that on the Spring MVC side.
Issue: SPR-15516
This comment extends the use of the charset property in
FormHttpMessageConverter to also include multipart headers with a
default of UTF-8.
We now also set the charset parameter of the "Content-Type" header to
indicate to the server side how to decode correctly.
Issue: SPR-15205
The MultipartHttpMessageWriter now directly encodes part header values
defaulting to UTF-8 and also specifies the charset in the
Content-Type header for the entire request.
This should work with something commonly used like Apache Commons
FileUpload which checks request.getCharacterEncoding() and uses it
for reading headers.
This commit turns the Synchronoss NIO Multipart HttpMessageReader into
a reader of Flux<Part> and creates a separate reader that aggregates
the parts into a MultiValueMap<String, Part>.
Issue: SPR-14546
This commit properly closes the opened channels in the SynchronossPart,
and also makes sure that the entire contents is copied, not just the
first batch.
Update `SpringFactoriesLoader` to cache property file loads. This helps
reduce the number of garbage objects created as each load uses an 8K
char buffer.
Issue: SPR-15509
This commit introduces a `writableChannel()` method to
`WritableResource`, defaulting to `Channels.newChannel`, but with
overrides for file-based resources.
Change the `StringHttpMessageConverter` to defer calling
Charset.availableCharsets() until absolutely necessary to help improve
startup times.
Issue: SPR-15502
With this commit, ServerCodecConfigurer is now exposed as a bean in
order to be provided to DefaultServerWebExchange via
WebHttpHandlerBuilder and HttpWebHandlerAdapter. This allows
DefaultServerWebExchange to get configured codecs for reading form or
multipart requests.
Issue: SPR-14546
This commit introduces reactive multipart support by adding a new
MultipartHttpMessageReader interface (with default methods) and a
SynchronossMultipartHttpMessageReader implementation based on
the Synchronoss NIO Multipart implementation
(https://github.com/synchronoss/nio-multipart).
Issue: SPR-14546
Until this change a single classloader was used to load
all compiled SpEL expressions. This meant in a context where an
expression was repeatedly flipping between compiled and interpreted
mode (which can happen if in MIXED mode compilation and changing
the context around the evaluation) the classloader would continually
load a new compiled version but not orphan the old compiled version.
This eventually uses up all the memory as the number of classes
is ever increasing.
With this change classloaders are used to load 100 compiled
expressions. The 101st will be loaded by a new one. Orphaning the
old classloader means if an expression is ever recompiled there
is more likely to be no anchored references left to the older
compiled form and it can be GC'd. In the MIXED situation above it
should help alleviate the problem of older classes never being
candidates for GC.
Issue: SPR-15460
This commit changes the handling of 4xx/5xx status codes in the
WebClient to the following simple rule: if there is no way for the user
to get the response status code, then a WebClientException is returned.
If there is a way to get to the status code, then we do not return an
exception.
Issue: SPR-15486
This commit renames `WebClient.ResponseSpec.bodyToEntity` to `toEntity`
and similarly renames `WebClient.ResponseSpec.bodyToEntityList` to
`toEntityList`. In both cases, the `body` prefix was dropped because the
return value contains more than the body.
Issue: SPR-15486
- Fixed AnnotationUtils.getValue() operation to ensure it re-throws AnnotationConfigurationException instead of swallowing it (as it is done in few other operations in AnnotationUtils)
- Added test
- Removed unnecessary '@SuppressWarnings("unchecked")'
According to RFC-6265 that there should be a space between the ; and
the attribute name, i.e. the header should be something like
name=value; Domain=localhost; HttpOnly rather than
name=value;Domain=localhost;HttpOnly
Issue: SPR-15225
Spring MVC now treats Flux<String> + "application/json" as (serialized)
text to be written directly to the response as is. This is consistent
with the rendering of String + "application/json".
Issue: SPR-15456
This commit renames the `body(Object)` on ServerResponse to
`syncBody(Object)`. The reason for this is that the original method
name clashed with the `body(Publisher)` method in the Kotlin extension.
The new name nicely reflects the synchronous nature of the method,
making it less appealing than the `Publisher`-based `body` method.
Issue: SPR-15467
Due to a bug in Rouge thats prevents it from working on MS Windows, we
are currently reverting back to CodeRay for source code highlighting
within the Reference Manual.
Issues: SPR-15471
This commit adds the ability for path patterns to automatically
match a trailing separator (so there is no need to add two
variants of a pattern, one with and one without). This behaviour
is currently turned off but a simple tweak in PathPatternParser
can make it the default. If made default other parts of Spring
may need altering (simplifying hopefully) to cope with this.
Issue: SPR-15260
This method introduces a new body(Object) to ServerResponse, a shortcut
to body(BodyInserters.fromObject(Object)).
Note that in the implementation of the method, an `instanceof` check is
performed to make sure that the passed argument is not a `Publisher`,
as users should call `body(Publisher, Class)` for sending a reactive
type.
This Publisher-check is also done in the `WebClient`, for the same
reasons.
Issue: SPR-15461
Without this change it was necessary to call getPathRemaining and
then chop up the path and make a call to matchAndExtract to get the
bound variables for the path part that matched. With this change
this is all done in the call to getPathRemaining which returns
an object holding the remaining path and the bound variables.
Issue: SPR-15419
This commit introduces QosSettings that gather the Qualify of Service
settings one can use when sending a message. Such object can now be
associated to any JMS endpoint that allows to send a reply as part of
the processing of an incoming message.
Issue: SPR-15408
Includes revised Log methods in log level order, with consistent delegation of fatal->error for log level checks in SLF4J and JUL, a JavaUtilDelegate for defensive access to java.logging on JDK 9, support for LogRecord message objects, as well as revised log setup recommendations.
Issue: SPR-15453
Issue: SPR-14512
This commit changes the `HandlerStrategies` and `ExchangeStrategies`
builders to use the `CodecConfigurer` for configuring Decoder|Encoder
and HttpMessage[Reader|Writer]. Other classes that use `CodecConfigurer`
have also been changed to reflect the refactoring to interfaces.
This commit also removes the ExchangeStrategies methods that take an
application context, as it was too naive approach to simply look up
every message reader and writer in the context.
Issue: SPR-15415, SPR-15435
This commit refactors the CodecConfigurer, with it's subtypes
ServerCodecConfigurer and ClientCodecConfigurerTests, into interfaces
instead of classes.
This commit introduces an explicit dependency on the latest JUnit
Vintage TestEngine so that it overrides whatever is bundled by
default in IntelliJ IDEA.
This allows for a more seamless upgrade to newer versions of JUnit 5 and
the JUnit Platform before IDEA has been officially updated to support
those versions, while simultaneously allowing developers to continue
to execute JUnit 4 based tests within IDEA.
This commit introduces an explicit dependency on the latest JUnit
Platform Launcher API so that it overrides whatever is bundled by
default in IntelliJ IDEA.
This allows a more seamless upgrade to newer versions of JUnit 5 and
the JUnit Platform before IDEA has been officially updated to support
those versions.
This commit changes the `HandlerStrategies` builder to use
`ServerCodecConfigurer` for configuring Decoder|Encoder and
HttpMessage[Reader|Writer]. Note that the configurer is not exposed
directly, but wrapped so that `HandlerStrategies` can keep on returning
`this` for a proper builder pattern.
This commit also removes the HandlerStrategies methods that take an
application context, as it was too naive approach to simply look up
every message reader and writer in the context.
Issue: SPR-15415
- Renamed `defaultCodec` to `defaultCodecs`, and `customCodec` to
`customCodecs`
- Added `@Override` annotations where necessary
- Fixed non-parameterized usage for parameterized types.
Previously a requestURI that contained ';' would have the value incorrectly stripped out when using
ForwardedHeaderFilter.
This commit ensures that the ';' is preserved when using ForwardedHeaderFilter.
Issue: SPR-15428
Previously ForwardedHeaderFilter would override the requestURI with a URL decoded value. This would cause
problems when using a URL encoded requestURI since downstream Filters would not see the URL encoded
value as they should.
This commit resolves this issue by ensuring that the requestURI is properly encoded.
Issues SPR-15422
This commit makes CodecException handling consistent between functional
and annotation-based APIs. It now returns by default 4xx status code
for decoding error and 5xx for encoding error + print the error reason
in logs without the full stack trace in both variants.
Issue: SPR-15355
The java.util.Optional wrapper should not affect the support for
"request param" arguments with or without the annotation as it
works on the Spring MVC side.
Previously ForwardedHeaderFilter would return the same StringBuffer for every invocation. This
meant that users that modified the StringBuffer changed the state of the HttpServletRequest.
This commit ensures that a new StringBuffer is always returned for ForwardedHeaderFilter.
Issue: SPR-15423
This commit uses the newly introduced
`PathPattern.getPathRemaining(String)` in the functional web framework.
With this change, all path predicates can be used for nested router
functions, so the `pathPrefix` predicate is no longer required and has
been removed.
Issue: SPR-15336
With this change there is a new getPathRemaining() method on
PathPattern objects. It is called with a path and returns
the path remaining once the path pattern in question has
matched as much as it can of that path. For example if the
pattern is /fo* and the path is /foo/bar then getPathRemaining
will return /bar. This allows for a set of pathpatterns
to work together in sequence to match a complete entire path.
Issue: SPR-15336
This commit uses a tip provided by @mojavelinux to set the syntax
highlighter to Rouge for the PDF version of the User Guide.
Once Asciidoctor 1.5.7 has been released we will likely switch to Rouge
for the HTML version of the Reference Manual as well.
Issue: SPR-14997
This commit introduces support for the server-side methods on
HttpMessageReader and HttpMessageWriter. It does so by introducing an
Optional ServerHttpRequest in BodyInserter.Context, and an Optional
ServerHttpResponse in BodyExtractor.Context. On the client-side, these
optionals return Optional.empty(); on the server-side, they return the
respective server-side messages.
Issue: SPR-15370
InvalidDefinitionException has been introduced in Jackson 2.9 to be
able to differentiate invalid data sent from the client (should still
generate a 4xx HTTP status code) from server side errors like beans with
no default constructor (should generate a 5xx HTTP status code).
Issue: SPR-14925
This commit converts interlaced PNGs to standard PNGs and uses PNGs
instead of GIFs consistently within the reference manual in order to
avoid issues with AsciiDoc’s support for inlined images.
Issue: SPR-14997
- ServletServerHttpResponse.ResponseAsyncListener#onError/onTimeout
must complete the async operation
- ServletHttpHandlerAdapter.HandlerResultSubscriber#onComplete must
check that the async operation is not completed
Issue: SPR-15412
This commit adds support for reactive library types to be returned
directly from controller methods adapting them either to a
ResponseBodyEmitter (streaming) or DeferredResult (non-streaming).
The reactive libraries supported are the ones that can adapted to a
Reactive Streams Publisher through the ReactiveAdapterRegistry.
Issue: SPR-15365
Revise Javadoc on AsyncHandlerMethodReturnValueHandler to clarify its
main purpose is to prioritze custom async return value handlers ahead
of built-in ones. Also replace the interface from built-in handlers
which are prioritized already.
Remove DeferredResultAdapter and ResponseBodyEmitterAdapter --
introduced in 4.3 for custom async return value handling, since for
5.0 we will add built-in support for reactive types and the value of
these contracts becomes very marginal.
Issue: SPR-15365
This change allows the functional WebFlux API to support natively
reactive types and also makes it possible for View implementations to
disable async attributes resolution if they want for example take
advantage of stream rendering.
It also makes AbstractView#getModelAttributes() asynchronous.
Issue: SPR-15368
Replace the overloaded "retrieve" methods with a single retrieve() +
ResponseSpec exposing shortcut methods (bodyToMono, bodyToFlux)
mirroring the ClientResponse shortcuts it delegates to.
Unlike exchange() however with retrieve() there is no access to other
parts of ClientResponse so ResponseSpec exposes additional shortcuts
for obtain ResponseEntity<T> or ResponseEntity<List<T>>.
Issue: SPR-15294
This commit makes a change to WebClient in oder to facilitate getting
the response body as a `Mono<Object>` or `Flux<Object>` without having
to deal with `ClientResponse`.
Specifically, this commit:
- Adds `RequestHeaderSpec.retrieve` methods, next to `exchange`, that
return the response body (and not a `ClientResponse`). Two convenience
methods return the response body as `Mono` or `Flux`.
- Adds ClientResponse.toRequestEntity to convert the ClientResponse
into a RequestEntity.
Issue: SPR-15294
The ServerCodecConfigurer is now passed all the way into the
RequestMappingHandlerAdapter which automatically enables the same
defaults even without the Java config and provides extra flexibility
in passing message codec configuration for the future.
This commit makes changes to WebClient and WebTestClient in oder to
limit setting the body according to HTTP method and also to facilitate
providing the request body as Object.
Specifically, this commit:
- Moves methods that operate on the request body to a RequestBodySpec
in both WebClient and WebTestClient, and rename them to `body`.
These methods now just *set* the body, without performing
an exchange (which now requires an explicit exchange call).
- Parameterizes UriSpec in both WebClient and WebTestClient, so that
it returns either a RequestHeadersSpec or a RequestBodySpec.
Issue: SPR-15394
This commit deprecates `AsyncRestTemplate` and related types
(`AsyncClientHttpRequestFactory` etc.) in favor of the Spring 5.0
`WebClient`.
Issue: SPR-15294
This commit removes docbook from the documentation toolchain and
instead makes use of asciidoctor to render the reference documentation
in HTML and PDF formats.
The main Gradle build has been refactored with the documentation tasks
and sniffer tasks extracted to their own gradle file in the "gradle"
folder.
A new asciidoctor Spring theme is also used to render the HTML5 backend.
Issue: SPR-14997
Extract controller method caches including associated code and
discovery of @ControllerAdvice components into a separate, package
private helper class (ControllerMethodResolver).
This commit folds ServerHttpMessage[Reader|Writer] into its parent
HttpMessage[Reader|Writer] with the server methods pre-implemented
by default to be simple pass-through delegates.
This commit changes `ResourceTransformerSupport` to look for the
`ResourceUrlProvider` in the current request if none is configured on
the resource transformer itself.
Issue: SPR-15369
Prior to this commit, the `VersionResourceResolver` implementations of
`resolveUrlPathInternal` would delegate to the resolver chain but would
never use the give result if the current request didn't match a
configured version strategy pattern.
This is a problem if the resolver supposed to resolve the resource path
is configured after a `VersionResourceResolver` in the resolver chain;
this means that other resolver never gets to participate in the result
of the chain.
Issue: SPR-15372
Includes a new overloaded ModelAndView constructor with an HttpStatus argument, as well as a HandlerMethodArgumentResolverSupport refactoring (revised checkParameterType signature, actually implementing the HandlerMethodArgumentResolver interface).
Issue: SPR-15199
Follow-up to:
https://github.com/spring-projects/spring-framework/commit/3d68c496f15c80a75711480a569cda1f7c64dc91
StringDecoder can be created in text-only vs "*/*" mode which in turn
allows a more intuitive order of client side decoders, e.g. SSE does
not have to be ahead of StringDecoder.
The commit also explicitly disables String from the supported types in
Jackson2Decoder leaving it to the StringDecoder in "*/*" mode which
comes after. This does not change the current arrangement since the
the StringDecoder ahead having "*/*" picks up JSON content just the
same.
From a broader perspective this change allows any decoder to deal with
String if it wants to after examining the content type be it the SSE
or another, custom decoder. For Jackson there is very little value in
decoding to String which works only if the output contains a single
JSON string but will fail to parse anything else (JSON object/array)
while StringDecoder in "*/*" mode will not fail.
Issue: SPR-15374
This commit introduces a `useRegisteredExtensionsOnly` property that
indicates whether classes that use the `MediaTypeFactory` for supplying
default media types can do so.
- In classes that were introduced in Spring 5.0, the
`useRegisteredExtensionsOnly` property takes the place of the
`useJaf` property that was removed in 0aaa652
- In classes that existed before Spring 5.0, the
`useRegisteredExtensionsOnly` property is added in addition to the
deprecated `useJaf`, the latter delegating to the former, but with
flipped behavior.
Issue: SPR-14908
This commit changes the `MediaTypeFactory` to return
`Optional<MediaType>` (instead of a plain `MediaType`) for the
`getMediaType` methods.
Issue: SPR-14908
CharSequenceEncoder now supports all MIME types, however since encoding
Flux<String> can overlap with other encoders (e.g. SSE) there are now
two ways to create a CharSequenceEncoder -- with support for text/plain
only or with support for any MIME type.
In WebFlux configuration we insert one CharSequenceEncoder for
text/plain (as we have so far) and a second instance with support for
any MIME type at the very end.
Issue: SPR-15374
Push the knowledge of what media types represent "streaming" down to
the Encoder level where knowledge is required (e.g. to encode a
JSON array vs a stream of JSON elements).
This commit changes `ServerResponse` and subtypes to use properties
instead of fields during response rendering. This allows for overriding
these methods in a response subclass.
This commit changes the `HandlerFilterFunction.ofResponseProcessor`
method signature to return `Mono<ServerResponse>`, to better cooperate
with response builders (which all return a `Mono`).
Instead of accepting List<Encoder|Decoder> and then look for the first
to support JSON, always expect a single JSON [Encoder|Decoder] and use
that unconditionally.
When writing use the nested ResolvableType instead of the Class of the
actual value which should better support generics.
Remove the SSE hint and pass "text/event-stream" as the media type
instead to serve as a hint. We are expecting a JSON encoder and using
it unconditionally in any case so this should be good enough.
Consolidate JsonView hint extraction in shared base class.
Rename base class from AbstractJackson2Codec to Jackson2CodecSupport
since the class mainly provides support methods.
ServerHttpMessage[Reader|Writer] are now expected for WebFlux,
annotated controller endpoint and subsequently the instanceof checks
for HttpMessage[Reader|Writer] vs ServerHttpMessage[Reader|Writer] can
be removed from AbstractMessageReaderArgumentResolver and
AbtractMessageWriterResultHandler.
Support for flushing in EncoderHttpMessageWriter is now driven from a
configurable list of "streaming" media types with the list including
"application/stream+json" by default.
As a result Jackson2ServerHttpMessageWriter is no longer needed.
ServerHttpEncoder and ServerHttpDecoder are HTTP-specific
specializations that can prepare encoding and decoding hints from
extra information available on the server side.
As a result Jackson2ServerHttpMessageReader is no longer needed.
There is a natural way to implement ServerHttpMessage[Reader|Writer]
from [Encoder|Decoder]HttpMessageWriter by resolving hints first via
a protected method and then delegating to the regular read or write.
There is no downside either since it does not prevent
[Encoder|Decoder]HttpMessageWriter from being used for both client and
server scenarios while they're more useful.
As a positive side effect AbstractServerHttpMessage[Reader|Writer] can
be removed further simplfications can be made (in a future commit) to
accept ServerHttpMessageWriter for configuration purposes on the server
side and remove instanceof checks for ServerHttpMessageWriter.
This commit changes the `MockServletContext.getMimeType` method to use
`MediaTypeFactory` instead of JAF. It also adds a `addMimeType(String,
MediaType)` method to customize the mime types returned from said
method.
Issue: SPR-14908
This commit updates the main code base to conform to the dropped JAF
dependency in MediaTypeFactory. Specifically, it
- Removes JAF detection (JAF_PRESENT constants)
- Deprecated useJaf properties, with no direct replacement.
- Updated docs to remove JAF references, in favor of MediaTypeFactory.
Issue: SPR-14908
This commit drops the Java Activation Framework dependency from the
MediaTypeFactory, in favor of parsing our own `mime.types` file, which
was obtained from Apache HTTPD.
Issue: SPR-14908
Fold ResourceRegionHttpMessageWriter into ResourceHttpMessageWriter.
The latter was a private helper (not meant to be exposed) and the two
have much in common now sharing a number of private helper methods.
The combined class does not extend AbstractServerHttpMessageConverter
from which it was not using anything.
Internally the combined class now delegates directly to ResourceEncoder
or ResourceRegionEncoder as needed. The former is no longer wrapped
with EncoderHttpMessageWriter which is not required since "resource"
MediaType determination is a bit different.
The consolidation makes it easy to see the entire algorithm in one
place especially for server side rendering (and HTTP ranges). It
also allows for consistent determination of the "resource" MediaType
via MediaTypeFactory for all use cases.
ResourceRegionHttpMessageWriter no longer extends from
EncoderHttpMessageWriter freeing it to pass the correct content type
into the encoder.
Considering that the main benefit of EncoderHttpMessageWriter is to
deal with content type fallback cases, there is nothing to be missed.
Furthermore ResourceRegionHttpMessageWriter is a package private class
that is used internally within ResourceHttpMessageWriter and never
exposed externally as a an actual HttpMessageWriter.
Issue: SPR-15358
When CodecHttpMessageConverter was split into DecoderHttpMessageReader
and EncoderHttpMessageWriter the null checks were never removed.
This commit makes the Encoder and Decoder instances provided to their
respective wrappers required.
ExchangeMutatorWebFilter now supports multiple mutator registrations
for the same request header id by creating a single composed function.
Issue: SPR-15250
CompositeHttpHandler is public and called ContextPathCompositeHandler.
Also an overhaul of the Javadoc on HttpHandler, WebHttpHandlerAdapter,
and ContextPathCompositeHandler.
Extract CompositeHttpHandler to a package private class and add direct
support via `HttpHandler.of(...)`. This removes the need for the
`HttpHandlerAdapterSupport` class.
Switch from extension to delegation model, i.e. delegating to
InvocableHandlerMethod, so that only sync invocation is exposed and
only resolvers of type SyncHandlerMethodArgumentResolver are allowed
to be configured in a cleaner fashion.
This commit adds a common base class for server-less setup with the
option to configure a transformation function on the
ServerWebExchange for every request.
The transformation is applied through a WebFilter. As a result the
RouterFunction setup is now invoked behind a DispatcherHandler with
a HandlerMapping + HandlerAdapter.
Issue: SPR-15250
Currently the BOM versions are:
* reactor-core 3.0.6.BUILD-SNAPSHOT
* reactor-netty 0.6.2.BUILD-SNAPSHOT
This commit fixes as well a few deprecations in reactor-core.
The WebTestClient API no longer provides access to a base
ExchangeResult without a decoded response body.
Instead the response has to be decoded first and tests can then
access the EntityExchangeResult and FluxExchangeResult sub-types.
This commit adds an overloaded DataBufferUtils.read method that operates
on a AsynchronousFileChannel (as opposed to a ReadableByteChannel, which
already existed). This commit also uses said method in the Resource
encoders, if the Resource is a file.
The SSE reader is ordered ahead of StringDecoder because with
response.decodeToFlux(String.class) we actually want the SSE reader
to get involved first based on the content-type.
At the same time with response.decodeToMono(String.class) there is
nothing the SSE reader can do while the StringDecoder could read the
entore content as one String, as long as the server does terminate
the stream which can happen in a testing scenario.
This commit updates ServerSentEventHttpMessageReader#readMono in
to support String.class by delegating to StringDecoder. Since
reading to a Mono is an explicit choice there is not much possibility
for interfering with decoding to Flux.
Issue: SPR-15331
This commit simplifies the use of DataBufferFactory in the SSE reader
which is used only to wrap a byte[] as a DataBuffer. There is no actual
benefit to use anything other than a DefaultDataBufferFactory.
From spring-webflux to spring-web test sources since it is perfectly
usable for testing Spring MVC annotation method support.
Potentially to be promoted further up for use in any module that has
annotation method support. It has spring-core dependencies only
In preparation for SPR-15132.
Turn the BindingContextFactory into ModelInitializer (both package
private) since creating BindingContext itself is quite simple.
The ModelInitializer also has only one field and no need to be aware
of fields the RequestMappingHandlerAdapter.
- typealias to replace types like RouterDsl.() -> Unit by Routes
- String.invoke() as path("/foo") shortcut
- String.route() as pathPrefix("/foo").route() shortcut
- Avoid requiring PathPredicates.* import
Issue: SPR-15292
This commit adds a trailing slash to the nested path if the request path
also ends with a slash. For instance, given the request "/foo/bar/", and
nested path pattern "/foo/**", we expect the nested path to be “/bar/”,
not “/bar".
`PathPatternParser` is now thread-safe and creates a new internal parser
for each `parse` call, since this operation is cheap.
This commit removes the `ThreadLocal` based instances of
`PathPatternParser` in `ParsingPathMatcher` which are not required
anymore.
Issue: SPR-15246
With this change the original PathPatternParser is renamed
InternalPathPatternParser and a new PathPatternParser class is added.
This new PathPatternParser class is a very simple thread-safe wrapper for
the InternalPathPatternParser. It achieves this by creating a new
InternalPathPatternParser for each new parse request. This follows the
model used for SpEL parsing.
The WiretapConnector now decorated the ClientHttpRequest & Response
in order to intercept and save the actual content written and read.
The saved content is now incorporated in the diagnostic output but may
be used for other purposes as well (e.g. REST Docs).
Diagnostic information about an exchange has also been refactored
similar to command line output from curl.
This commit improves `AbstractValueAdaptingCache` to throw a dedicated
exception if `allowNullValues` is `false` and a `null` value is provided
anyway. This avoid a lower-level exception from the cache library that
will miss some context.
Issue: SPR-15173
Prior to this commit, the `ShallowEtagHeaderFilter` could participate in
the response and set its ETag/Content-Length headers, even for HEAD
requests. Since the response body is empty, the filter implementation
would set a `"Content-Length: 0"`.
The RFC states that responses to HEAD requests should exhibit identical
response headers to GET (with the possible exception of payload related
headers such as Content-Length.
With this commit, `ShallowEtagHeaderFilter` now ignores HEAD requests
since the proper values may be set already for payload related headers
by the handler. The filter has no way to generate a proper ETag value
nor calculate the content length without the actual body.
Issue: SPR-15261
Clearly separate how the result of an exchange is represented before
the response body has been read (e.g. assertions on status and headers
only) vs later after the body is extracted to a representation
(assertions on the extracted body) or is decoded to Flux<T> (e.g. for
use with a StepVerifier).
The first fix for issue 15264 covered the case of using a single
variable (the case mentioned in the bug report). However, when
more than one variable is used a different PathElement is built.
This RegexPathElement needs a similar change that checks the
path includes data to bind.
Issue: SPR-15264
WebTestClient now defines all the steps from setup to performing
an exchange and applying expectations.
The order of expectations now ensures the response status and headers
are verified first since that's available before the body is consumed
and also because it determines how the body is to be decoded, i.e.
error vs success scenarios.
There is now a built-in option for verifying the response as a Map
along with Map-specific assertions.
There are similar options for verifying the response as a List as well
as whether to "collect" the list or "take" the first N elements from
the response stream.
Rather than returning ExchangeActions that contains ExchangeInfo and
applies a chain of assertions, the exchange operation in WebTestClient
now has an extra step to decode the response.
The outcome of that is ExchangeResult<T>, parameterized with the
decoded body type, and containing the request and response details,
also providing access to built-inassertions via an assertThat()
instance method.
This approach lends itself better to decoding and asserting response
body types with generecis. It is also more friendly to using any
assertion library such as AssertJ since you get the result first
and then deal with assertions.
Removed `json()`, `html()` and `xml()` from `RequestPredicates`, since
they were confusingly named and would also require a counterpart that
reads the request `Content-Type` instead of the `Accept` header.
Renamed `RouterFunction.andSame()` to `and()`, and `and()` to
`andOther()`. The reason for this change is that we can expect most
RouterFunctions to be parameterized over ServerResponse, and thus it
makes sense to use the shortest composition method (`and()`) for
composing router functions of the same type.
When a user composes different response types, such as composing a
`RouterFunction<RenderingResponse>` with an
`RouterFunction<EntityResponse<?>`, the `andOther` method is to be used,
but this is a less common scenario.
This commit checks that a "Content-Length" request header isn't already
present before adding one in `Netty4ClientHttpRequestFactory`.
`HttpMessageConverter` implementations can write that request header so
the Netty request factory should only write that value when the header
is missing.
If that header is not written (and since we're not dealing with
the HTTP exchange in a chunked-based fashion), the HTTP client might not
send the request body at all.
Issue: SPR-15241
This commit changes the `assertXmlEqual` implementation to compare
expected and actual XML documents without considering the order of XML
nodes.
Issue: SPR-15156
Added RequestPredicate for JSON, HTML, and XML requests. All three tests
for their respective mime type in the Accept header, as well as checking
for a file extension.
Put assertBodyXyz options behind a common assertBody() entry point
currently including "isEmpty" and "asMap" but in the future others
related to JSON content or XPath for example.
Now that ExchangeActions provides method to access the ExchangeInfo
it has been removed from constructors of assertion classes that
already have ExchangeActions.
This commit ensures that the `PathPatternParser` and the associated
cache map are used in a threadsafe fashion, since the PathMatcher
instance can be used for concurrent requests.
Issue: SPR-15246
This commit removes the parameterisation from ClientRequest, similarly
to ServerResponse. Dropping the parameterisation facilitates a
ClientRequest.from method that also copies the body of the target
request.
SPR-15234 Work in Progress
This commit reduces the exposition of `PathPattern` instances throughout
the `HandlerMapping` API and removes some methods from its public API.
Issue: SPR-14544
We need to explicitly apply Dependency Management to the root
project since it depends on modules that use dependency management.
We need to ensure dependency management is applied after propdeps-maven
to avoid an ordering issue [1]
An update to propdeps was necessary to be compatable with Gradle
3.4+
[1] https://github.com/spring-gradle-plugins/dependency-management-plugin/issues/149
Issue: SPR-15207
This commit reverses 9efa976d31, and adds
code comments to highlight why some Body[Inserter|Extractor] instances
returned from Body[Inserters|Extractors] use
ServerHttp[Request|Response] instead of using
Reactive[Input|Output]Message.
Since the introduction of `PathPatternRegistry`, the various path match
configuration flags are no longer needed in several places and that
configuration can live in the registry itself.
Issue: SPR-14544
This commit adds the new `PathPatternRegistry`, which holds a
sorted set of `PathPattern`s and allows for searching/adding patterns
This registry is being used in `HandlerMapping` implementations and
separates path pattern parsing/matching logic from the rest. Directly
using `PathPattern` instances should improve the performance of those
`HandlerMapping` implementations, since the parsing and generation of
pattern variants (trailing slash, suffix patterns, etc) is done only
once.
Issue: SPR-14544
Without this change the /{*foobar} and /** path elements were
not correctly enforcing that the first character they encounter
must be a separator. This problem was introduced when adjusting
the generated path element chains for these constructs. Originally
the generated chain included a SeparatorPathElement but in order for
these to match 'nothing' (i.e. /foo matches /foo/{*foobar}) the separator
path element was removed, so the separator enforcement needed moving
into the CaptureTheRestPathElement and WildcardTheRestPathElement.
Issue: SPR-14544
This commit introduces a PathPatternParser which parses request pattern
strings into PathPattern objects which can then be used to fast
match incoming string paths. The parser and matching supports the syntax
as described in SPR-14544. The code is optimized around the common usages
of request patterns and is designed to create very little transient
garbage when matching.
Issue: SPR-14544
Prior to this commit, WebFlux would look at the handler method
annotations (`@ResponseStatus`) for each handler execution, even calling
the expensive `synthesizeAnnotation`.
This commit moves this logic to the InvocableHandlerMethod so that this
executed once at instantiation time and for all result handlers.
Issue: SPR-15227
Before this change the write Publisher was saved and Mono.empty()
returned from the write metohd which did not properly implement
the write contract since no writing ("consuming") was done.
This can be a problem in some cases. For example the request may appear
to succeed even if the publisher produces an error later when
subscribed to later after request handling completes.
This commit introduces a writeHandler function in the mock request and
response. By default it "writes" by consuming the content immediately,
which allows it to return a Mono<Void> that properly reflects when
writing is done, and it also caches the data so it may be replayed
later for test assertions.
For streaming scenario a custom writeHandler may be registered which
allows the custom handling to determine how long to stream before
cancelling so request handling may complete.
Issue: SPR-14590
Without this fix the compiled version of elvis
actual behaved differently to the interpreted version
if the value being queried was an empty string. This
is now fixed. It also now correctly handles the
query value being a primitive and addresses the
findings of SPR-15192 where some type inferencing
logic was trying to be too clever, that code has
been deleted.
Issue: SPR-15192
This commit introduces JSON streaming support which
consists of serializing HTTP request with
application/stream+json media type as line delimited JSON.
It also optimize Flux serialization for application/json by
using flux.collectList() and a single Jackson invocation
instead of one call per element previous strategy.
This change result in a x4 throughput improvement
for collection with a lot of small elements.
Issues: SPR-15095, SPR-15104
This commit makes sure that the `ErrorHandler` is invoked if the cache
fails to put an element (be it in the main cache or the exception cache).
See gh-1292
Issue: SPR-15188
The base URI is ignored for requests that include a host.
WebClient exposes UriBuilder (rather than UriBuilderFactory) for
per-request URI building based on the base URI. That provides
full control to add or replace components of the base URI.
Leave only one static, no-arg build() method for access to a Builder.
URI-related preferences are now exposed on the builder itself.
Improve Javadoc with base URI examples.
This commit makes the following changes:
- Merge WebClient into ExchangeFunction. Static methods on WebClient
have been moved to the utility class ExchangeFunctions, similar to
RouterFunctions operates on the server side.
- Renamed WebClientOperations to WebClient.
- Renamed WebClientStrategies to ExchangeStrategies
This commit removes the use of SocketUtils#findAvailableTcpPort in
favor of letting servers pick a dynamic port by specifying port 0.
This should make integration tests more stable because the port is
chosen at the place where it needs to be used. It gives servers a
chance to try to open a socket on some port and start using the socket
if successful.
This commit *adds* the "intercepted" headers to the ClientHttpRequest,
as opposed to replacing them, which is what happened before this commit.
Issue: SPR-15166
Following on the introduction of the UriBuilderFactory and its
DefaultUriBuilderFactory implementation, this commit deprecates
DefaultUriTemplate (and AbstractUriTemplateHandler).
The new DefaultUriBuilderFactory has comparable functionality and is
more flexible but cannot be merged into the existing hierarchy and
be backwards compatible with regards to protected methods.
Issue: SPR-15124
Following on the introduction of WebClientOperations in the last commit
this commit removes the HTTP method specific factory methods and also
scales back the builder options in ClientRequest.
ClientRequest is now expected to be used mainly from an
ExchangeFilterFunction which may modify the ClientRequest using the
from(ClientRequest) entry point rather creating from scratch.
Issue: SPR-15124
Due to the static nature of JUnit parameterized test inputs, an
HttpServer instance is re-used for all tests per test class.
This commit adds lifecycle handling to AbstractHttpServer with a
lifecycle monitor to ensure test server fields are properly
initialized and reset after each test .
Introduce separate adapters TomcatHttpHandlerAdapter/JettyHttpHandlerAdapter
so that each adapter can use the Tomcat/Jetty APIs for reading/writing
with ByteBuffer.
Failures in JettySockJsIntegrationTests after the upgrade to 9.4 were
hidden due to the PERFORMANCE test group but were failing on the CI
performance build with IllegalStateException inside Jetty on
"Failure find the required ServletContext attribute
org.eclipse.jetty.util.DecoratedObjectFactory".
Prior to this commit, SpringJUnit4ConcurrencyTests was broken due to
recent additions of test methods in SampleTests.
This commit fixes the broken test by removing hard coded constants and
replacing them with dynamic lookups for JUnit 4 @Test methods.
This also updates the version numbers provided in the sample pom.xml
snippets for configuring logging for SLF4J and Log4j 1.x. A sample
log4j2.xml file is also given with the same configuration as
demonstrated in the log4j.properties example. The link to the Log4j 1.x
site has been fixed to point to the 1.2 URL (do note that Log4j 1.2 is
end of life and is not compatible with JDK 9+).
See gh-1279
A bogus pre-release of Kotlin 1.1.0-beta-17 seems to be
in Spring Artifactory cache, this change make Gradle using
the right one from Bintray. Using --refresh-dependencies
may be needed to pick-up the right one.
Previously, the dependency management and propdeps-maven plugins
were being applied to all projects. The latter caused a problem with
publishing to Artifactory as the buildSrc project now had the
propdeps-maven plugin applied to it.
This commit removes the logic that was applying the propdeps-plugin
to all projects so that it's only applied to subprojects excluding
the buildSrc project. The logic that applies the dependency management
plugin has been moved to the same location. It is applied after the
propdeps-maven plugin as, otherwise, the pom customization does not
work correctly and optional dependencies are not included in
generated poms.
Issue: SPR-15167
This commit maps the UnsupportedMediaTypeException, used by both client
and server, to a server-side UnsupportedMediaTypeStatusException in the
functional web framework.
Prior to this commit, the org.springframework.tests.Assume class could
fail to load resulting in a NoClassDefFoundError if parsing of the
'testGroups' system property failed. This is because the parsing took
place while initializing a static field.
This commit addresses this issue by moving the 'testGroups' system
property lookup to a dedicated method that is lazily invoked upon
demand instead of eagerly when loading the Assume class itself.
In addition, when an error occurs, TestGroup.parse() now logs the
complete original value of the supplied test groups string instead of
potentially omitting the "all-" prefix. This results in more
informative error messages similar to the following.
java.lang.IllegalStateException: Failed to parse 'testGroups' system
property: Unable to find test group 'bogus' when parsing testGroups
value: 'all-bogus'. Available groups include:
[LONG_RUNNING,PERFORMANCE,JMXMP,CI]
Issue: SPR-15163
The generic encode method in UriUtils that encodes any character
outside the reserved character set for a URI is meant for "strict"
encoding of URI variable values. This commit adds a couple more
conveninence methods that accept a Map or array of URI variable
values to encode.
This facilitates the use case where the URI template is assumed to
be encoded while URI variables are encoded strictly to avoid any
possibility for unwanted reserved characters:
Map<String, ?> encodedUriVars = UriUtils.encodeUriVariables(uriVars);
uriComponentsBuilder.build(true).expand(encodedUriVars).toUri();
Issue: SPR-14970
Moved UnsupportedMediaTypeException next to Body[Inserters|Extractors],
as that is where they are used. This move should have been done as part
of the inserter and extractor move, but was forgotten.
This commit ensures that verifying a request, which includes finding
and updating expectations, is done synchronously to avoid concurrent
modification exceptions.
Technically SimpleRequestExpectationManager is not even expected to see
concurrent requests by definition but with
UnorderedRequestExpectationManager it can happen.
Issue: SPR-15029
In addition to the updates from PR#1297 this commit adds an integration
test and fixes for the resulting failures with RxNetty, Reactor Netty,
and Undertow.
Also replaced use of URLDecoder which is not for decoding URIs with use
of UriUtils for decoding query parameters.
Issue: SPR-15140
%-encoded strings were injected undecoded into @RequestParam variables,
which does not coincide with spring-webmvc behaviour. This commit
fixes AbstractServerHttpRequest.getQueryParams() to correctly return
decoded name-value pairs.
Issue: SPR-15140
This commit adds a DataBuffer Encoder and Decoder, and uses it in
the annotation-based processing model.
Note that these codecs are not used in the functional processing model,
since the BodyInserter/BodyExtractor already have methods for
writing/reading DataBuffers.
Issue: SPR-15148
This modification fixes the way AbstractView retrieves the
RequestDataValueProcessor bean, correctly returning null if there
is no bean of such type at the Application Context.
This avoids an exception in RedirectView (which extends AbstractView)
when trying to post-process the URL generated for redirection, when
no RequestDataValueProcessor exists.
Issue: SPR-15136
This commit changes RouterFunctionDsl {...} (request)
to route(request) {...}, remove uneeded methods, add
missing ones and add tests useful to validate the
DSL syntax and behavior.
Issue: SPR-15065
MockServerHttpRequest and MockServerHttpResponse now extend the same
abstract base classes that server-specific implementations do and
therefore approximate their behavior more closely.
As an immediate consequence MockServerHttpRequest is read-only after
it is created. Instead it now exposes static builder methods similar
to those found in RequestEntity. This enforces more strictness as well
as recycling of requests in tests and provides nicer builder methods.
To simplify tests DefaultServerWebExchange now offers a constructor
with just a request and response, and automatically creating a
DefaultWebSessionManager.
The spring-test module now also contains client-side reactive mock
request and response implementations. The mock client request extends
the same AbstractClientHttpRequest as client-specific implementations
do. There is no abstract base class for client responses.
Issue: SPR-14590
We should no longer rely on MYISAM for the sequence table since this
engine might not always be available. After this change the storage
engine used by the sequence table can be MYISAM or INNODB since the
sequences are allocated using a new connection without being
affected by any other transactions that might be in progress.
To allow users to fall back on the original functionality of using
MYISAM tables for the incrementer, we add a `useNewConnection` flag to
indicate whether or not to use a new connection for the incrementer.
This flag defaults to true.
Issue: SPR-15107
This commit introduces a router DSL for RouterFunctions
and RouterFunction in order to be able to write idiomatic
Kotlin code as below:
fun route(request: ServerRequest) = RouterFunctionDsl {
accept(TEXT_HTML).apply {
(GET("/user/") or GET("/users/")) { findAllView() }
GET("/user/{login}") { findViewById() }
}
accept(APPLICATION_JSON).apply {
(GET("/api/user/") or GET("/api/users/")) { findAll() }
POST("/api/user/") { create() }
POST("/api/user/{login}") { findOne() }
}
} (request)
Issue: SPR-15065
Put the lambda parameter at the end and use a function
instead of a supplier to be able to register beans like this:
val context = GenericApplicationContext()
context.registerBean(Foo::class)
context.registerBean{ Bar(it.getBean(Foo::class)) }
Issue: SPR-15118
Based on an idea from Mario Arias, we can avoid requiring specifying
explicitly Supplier lambda type in Kotlin API by declaring the supplier
parameter as "crossinline supplier: () -> T" instead of
"supplier: Supplier<T>".
Issue: SPR-15118
After the upgrade to JUnit Jupiter 5.0 M3, JUnit Jupiter tests in the
Spring build were no longer executed due to the introduction of a
default test class name pattern.
This commit addresses this issue by making use of the
@IncludeClassNamePatterns to specify that *TestCase test classes should
be executed within the org.springframework.test.context.junit.jupiter
package.
Prior to this commit, the `ResourceHttpMessageConverter` would support
converting from an `HttpInputMessage` to a `InputStreamResource`. This
is valid when reading resources on the server side, but it's not
compatible with the way `RestTemplate` works.
The API exposed by `RestOperations` imply that the HTTP server response
should be fully consumed and properly closed by the time the `exchange`
method returns. In other words, this HTTP client does not support
streaming the HTTP response.
This commit allows the `ResourceHttpMessageConverter` to be configured
to disable read streaming when used in `RestTemplate`.
Issue: SPR-14882
Codacy warns us that there are several references to Boolean
constructors in the tests. Direct usage of the Boolean constructor is
discouraged and even deprecated in Java 9 [1]. Boolean constructor use
can easily be replaced with the constant instances.
This commit contains the following changes:
- replace references to Boolean constructors with boolean constants in
JSP tag tests
- update the copyright year where necessary
- BooleanComparatorTests is intentionally left unchanged as it should
also work with the non-constant instances correctly
[1] http://download.java.net/java/jdk9/docs/api/java/lang/Boolean.html#Boolean-boolean-
Issue: SPR-15076
Codacy warns about an Error Prone [1] use of the double constructor of
BigDecimal in tests. The reason given is that it is a source of
precision loss if the number does not have an exact double
representation. The recommendation is to use the String constructor of
BigDecimal instead as it does not require using a lossy argument.
This commit contains the following changes:
- replace usage of the double constructor of BigDecimal with the
String constructor of BigDecimal in JdbcTemplateQueryTests
- update the copyright year
[1] http://errorprone.info/bugpattern/BigDecimalLiteralDouble
Issue: SPR-15077
ScriptUtils contains two calls to String#toCharArray for the sole
purpose to iterating over all chars in a String. Not only is this
unnecessary and can be replaced with String#charAt it also causes
additional allocator and heap pressure because String#toCharArray
rather than returning the backing array (which is gone in Java 9)
creates a copy.
This commit contains the following changes:
- remove String#toCharArray from ScriptUtils and replace with
String#charAt
Issue: SPR-15075
Prior to this commit, the `ResourceRegionHttpMessageConverter` would
rely on the default implementation of `getDefaultContentType` to guess
the default Content-Type of the resource region to be written to the
HTTP response. That implementation fetches the first media type
provided in the HTTP request "Accept" header.
This behavior is not correct when converting resources and this commits
aligns this converter with the `ResourceHttpMessageConverter` which uses
JAF to guess the correct Content-Type of the given resource, or just
returns "application/octet-stream" as a default value.
Issue: SPR-15041
Kotlin JSR 223 support currently requires kotlin-script-util
dependency (jcabi-aether, maven-core and aether-api can be
excluded since they are only used for live import of
dependencies and bring a lot of JARs in the classpath) and a
/META-INF/services/javax.script.ScriptEngineFactory
file specifying the ScriptEngineFactory to use, in that case
org.jetbrains.kotlin.script.jsr223.KotlinJsr223JvmLocalScriptEngineFactory.
Issue: SPR-15059
Needed for Kotlin script and JSR 223 support, and a good target
for Spring Framework 5.0 since it will allow features like generating
Java 8 bytecode, JDK 9 support, annotation array attribute single
value without arrayOf(), etc.
We ensure Kotlin 1.0 compatibility by setting apiVersion and
languageVersion compiler options to 1.0.
Issue: SPR-15059
When connecting with a ReconnectStrategy we can only report the outcome
of the first connect to the ListenableFuture<Void> return value.
Failures for all subsequent attempts to reconnect however must be
channeled to TcpConnectHandler#afterConnectFailure which is used in
the STOMP broker relay for example to publish
BroadcastAvailability(true/false) events.
When decoding STOMP messages unread portions of a given input ByteBuf
must be kept until more input is received and the next complete STOMP
frame can be parsed.
In Reactor Net 2.x this was handled for us through the "remainder"
field in NettyChannelHandlerBridge. The Reactor Netty 0.6 upgrade
however applied only a simple map operator on the input ByteBuf
after which the buffer is relased.
This commit replaces the use of a simple map operator for decoding
and installs a ByteToMessageDecoder in the Netty channel pipeline
which has a built-in ability to preserve and merge unread input into
subsequent input buffers.
reactor-netty-0.6.0.RELEASE on Maven Central depends on
reactor-ipc-0.6.0.RELEASE so no need for this repository anymore.
It may be needed to cleanup Gradle or Maven local cache
since preliminary version of reactor-netty-0.6.0.RELEASE
had a dependency on reactor-ipc-0.6.0.BUILD-SNAPSHOT.
This commit removes the statically created XnioWorker which is an
"active" component and should not be created automatically and could
lead to resource leaks. Instead XnioWorker is now required at
construction aligning better with WebSocketClient#connectionBuilder
which also does not have a "default" worker option.
Since the XnioWorker is the main input for creating a ConnectionBuilder
we now create the ConnectionBuider in a protected method and then allow
a Consumer<ConnectionBuilder> to configure it further as opposed to the
Function<URI, ConnectionBuilder> used previously.
This commit also removes default SSL context initialization for RxNetty
to better align with other client implementations.
Issue: SPR-14527
The HandlerSubcriber from each listener session implementation is now
consolidated into AbstractListenerWebSocketSession since the handling
of onComplete or onError in any case is about delegating to the
session.
This also allows for the UndertowWebSocketHandlerAdapter to become
simply an (Undertow) AbstractReceiveListener.
Issue: SPR-14527
This commit removes the base class WebSocketHandlerAdapterSupport which
was mainly a container for properties. Instead we use a
java.util.Function to create the WebSocketSession which differs in any
way by client and server, which in turn allows HandshakeInfo to become
a simple immutable container once again.
Also for Undertow the WebSocketConnectionCallback implementation has
been moved into the server.upgrade package since it is for server-side
use only.
Issue: SPR-14527
The most common use case is specifying JSON views.
ServerResponse.BodyBuilder#hint(String, Object) allows to
specify response body serialization hints.
ServerRequest#body(BodyExtractor, Map) allows to specify
request body extraction hints.
Issue: SPR-15030
- RxNettyWebSocketSession filters out WebSocketCloseFrame again
- add before/afterHandshake helper methods in WebSocketClientSupport
- log request headers on server and response headers on client
- polish 400 request handling in HandshakeWebSocketService
WebSocket frames are now aggregated through a Netty decoder so that
we always receive fully assembled messages by default capped at 64K.
Issue: SPR-14527
Rename classes not specific to Tomcat:
TomcatWebSocketSession -> StandardWebSocketSession
TomcatWebSocketHandlerAdapter -> StandardWebSocketHandlerAdapter
WebSocketSessionSupport is renamed to AbstractWebSocketSession since it
actually is a WebSocketSession and pre-implements a number of methods.
ServerEndpointRegistration is now package private (mainly for use in
upgrade strategies) and renamed to DefaultServerEndpointConfig.
Switch from returning Mono<WebSocketSession> to take a WebSocketHandler
and return Mono<Void> for the entire session handling.
The WebSocketHandler callback delimits the stard and end of protocol
handling and forces the handler to operate within the scope of the
Reactor operators.
Give the full duplex nature of WebSockets, the symmetry between client
and server (each now using WebSocketHandler) also seems appropriate.
Issue: SPR-14527
The WebSocketHander adapters are now neutral for client vs server-side
use with the adapters for RxNetty and Reactor Netty (server-side only)
completely removed.
A new HandshakeInfo carries information about the handshake including
URI, headers, and principal from the upgrade strategy, to the adapter,
and then to the session.
WebSocketSession exposes the HandshakeInfo as well reducing its overall
number of methods.
Move WebSocketMessage factory methods to the WebSocketSession which
has the bufferFactory() needed to create message payloads.
WebSocketMessage is left with one public constructor.
WebSocketMessage exposes convenience retain/releasePayload methods.
Expose bufferFactory() at the WebSocketSession level for creating
payloads like ReactiveHttpOutputMessage does.
Promote getId(), getUri(), and bufferFactory() to the base class
WebSocketSessionSupport.
Apply the new HttpHeaders#getAcceptLanguageAsLocale() in places where
it was hardcoded or defaulting.
Apply ServerHttpResponse.encodeUrl in RequestContext.
Issue: SPR-15024
An update on the last commit switching from:
List<Locale> getAcceptLanguageAsLocales() to
Locale getAcceptLanguageAsLocale()
This best supports the scenario for the most preferred Locale.
If there is a need to look at the prioritized list of languages it's
best to use Locale.filter with the LocaleRange's.
This is explained in the Javadoc for getAcceptLanguage().
Issue: SPR-15024
The use of Locale.LanguageRange for the Accept-Language header makes
sense as it gives the most flexibility for a client to set a weighted
list and for a server to do filtering via Locale#filter.
This commit adds an additional convenience method that turns
the LangugeRange list to a list of Locale's also filtering out a
wildcard (i.e. "*"). A List<Locale> is the most basic way to access
prefered languages and needed when filtering is not required.
Issue: SPR-15024
Previously ForwrdedHeaderFilter did not ensure that
HttpServletResponse.sendRedirect worked properly based on
X-Forwarded-* headers.
This commit updates ForwardedHeaderFilter to overrided the
HttpServletResponse.sendRedirect method to ensure
X-Forwarded-* headers are honored.
Issue SPR-15020
ServerWebExchange.Builder has an additional Consumer-style shortcut
method that accepts a builder for modifying the request.
ServerWebExchange and ServerHttpRequest builders have fewer methods,
more use-case focused vs matching directly to properties.
ServerWebExchange now provides access to "requestParams" as a
MulitValueMap with query parameters and form data combined.
The combined map is then used for the params condition of
@RequestMapping purposes () and also for @RequestParam arguments.
Issue: SPR-15000
This is similar to the WriteListener changes on the ServerHttpResponse
where we are more naturally exposed to a delayed write. Nevertheless
we could also have a delayed read and should be consistent. The early
initialization of the RequestBodyPublisher also simplifies the
internal implementation a bit.
Instead of registering an AsyncListener in ServletHttpHandlerAdapter
we now register an AsyncListener in each of the request and response
where the events need to be handled anyway. This allows removing the
package private delegation methods in the request and response.
This commit makes it possible for handler functions to return
asynchronous status codes and headers, by making HandlerFunction.handle
return a Mono<ServerResponse> instead of a ServerResponse. As a
consequence, all other types that deal with HandlerFunctions
(RouterFunction, HandlerFilterFunction, etc.) had to change as well.
However, when combining the above change with method references (a very
typical use case), resulting signatures would have been something like:
```
public Mono<ServerResponse<Mono<Person>>> getPerson(ServerRequest request)
```
which was too ugly to consider, especially the two uses of Mono. It was
considered to merge ServerResponse with the last Mono, essentialy making
ServerResponse always contain a Publisher, but this had unfortunate
consequences in view rendering.
It was therefore decided to drop the parameterization of ServerResponse,
as the only usage of the extra type information was to manipulate the
response objects in a filter. Even before the above change this was
suggested; it just made the change even more necessary.
As a consequence, `BodyInserter` could be turned into a real
`FunctionalInterface`, which resulted in changes in ClientRequest.
We did, however, make HandlerFunction.handle return a `Mono<? extends
ServerResponse>`, adding little complexity, but allowing for
future `ServerResponse` subtypes that do expose type information, if
it's needed. For instance, a RenderingResponse could expose the view
name and model.
Issue: SPR-14870
Similar pattern as for ServerWebExchange with a default mutate method
on ServerHttpRequest returning a Builder and eventually creating an
immutable wrapper.
HttpHandlerAdapterSupport uses the builder to set the contextPath.
Remove duplicated ServerHttpResponse#setComplete also declard in the
parent ReactiveHttpOutputMessage interface.
Also rename:
ServerWebExchange.MutativeBuilder --> ServerWebExchange.Builder
This commit makes it possible for a ChannelInterceptor to override the
user header in a Spring Message that contains a STOMP CONNECT frame.
After the message is sent, the updated user header is observed and
saved to be associated with session thereafter.
Issue: SPR-14690
Now that reactor/reactor-netty#12 is fixed, we can restore the
previously ignored integration tests.
New tests are hanging, so this commit is converting the `StepVerifier`
`verify()` calls to using actual timeouts.
Issue: SPR-14975
The WebSocketHandler adapters for all runtimes now extend
WebSocketHandlerAdapterSupport, which now also exposes
a shared DataBufferFactory property initialized from the response.
Issue: SPR-14527
suspend/resumeReceiving in the AbstractListenerWebSocketSession are
now abstract methods. In Tomcat/Jetty these methods are no-op
implementations that are then coupled with a buffering strategy via
Flux#onBackpressureBuffer. In Undertow they rely on flow control for
receiving WebSocket messages.
Issue: SPR-14527
- Added suspended flag to indicate whether the ReceivePublisher
is able to process the incoming messages.
- Use buffer strategy for the incoming messages.
Issue: SPR-14527
Dropped "Support" from the name since it not only provides support
methods but actually implements WebSocketSession.
Renamed inner classes:
WebSocketMessagePublisher -> WebSocketReceivePublisher
WebSocketMessageProcessor -> WebSocketSendProcessor
Add protected getter for sendProcessor.
Reduce scoping:
WebSocketReceivePublisher -> private
WebSocketSendProcessor -> protected
WebSocketSendProcessor#setReady -> public (class is still protected)
A few more method name alignments and Javadoc updates.
Issue: SPR-14527
AbstractRequestBodyPublisher and AbstractResponseBodyProcessor are now
used for WebSocket messages too and have been renamed more generally to
AbstractListenerReadPublisher and AbstractListenerWriteProcessor.
Issue: SPR-14527
This commit also migrates from a WeakHashMap to a ConcurrentReferenceHashMap, allowing for concurrent access to existing cache entries.
Issue: SPR-15006
When getting the lookup path of a resource, both query params and hashes
should be removed from the request path.
This commit fixes the public path resolution for paths like
`/resources/main.svg#icon-hamburgermenu`.
Issue: SPR-14928
Prior to this commit, `@ExceptionHandler` methods could not be injected
with `RedirectAttributes` arguments. This would make it impossible to
handle an error by redirecting to another view and add flashmap
attributes, to be included in the model when the next view is called.
Here is an example:
```
@ExceptionHandler(MyException.class)
public String handleException(MyException ex, RedirectAttributes
redirectAttributes) {
redirectAttributes.addFlashAttribute("errorMessage",
"This is an error message");
return "redirect:/";
}
```
This commit adds a new `RedirectAttributesMethodArgumentResolver`
instance in the list of pre-configured `HandlerMethodArgumentResolver`
in `ExceptionHandlerExceptionResolver`.
Issue: SPR-14651
Due to a few changes in `WebSocketServerFactory` and `Session` API, our
`JettyRequestUpgradeStrategy` and `JettyWebSocketSession` needed to
adapt. As of 9.3.15+ and 9.4.0+, some reflection is required to support
previous versions.
Spring 5.0 supports Jetty 9.3 and 9.4.
Issue: SPR-14940
This commit ensures that POST/PUT requests sent by the Netty client have
a Content-Length header set.
Integration tests have been refactored to use mockwebserver instead of
Jetty and have been parameterized to run on all available supported
clients.
Issue: SPR-14860
This commit changes RouterFunctions.toHttpHandler to return
HttpWebHandlerAdapter (instead of HttpHandler), so that WebFilters and
WebExceptionHandler can be applied to it.
Issue: SPR-14979
This commit adds the ability to serve Resources (static files) through a
RouterFunction. Two methods have been added to RouterFunctions: one that
exposes a given directory given a path pattern, and a generic method
that requires a lookup function.
Issue: SPR-14913
Create a ReactorNettyCodec to hold the decoding and encoding function
and consumer along with a package-private sub-class that delegates to
StompDecoder and StompEncoder.
Issue: SPR-14531
* getBeanDefinitionNames defensively returns a copy of the bean definition names array.
* copyConfigurationFrom provides an independent AutowireCandidateResolver instance and copies a ConversionService and dependency comparator configuration as well.
* findAutowireCandidates only considers a self reference fallback for direct dependency declarations, not as a collection element.
Issue: SPR-14897
Issue: SPR-14921
Issue: SPR-14965
In general, web.util is supposed to remain lowest-level, not depending on any other web.* package. Since web.client also has a support package, a corresponding web.server.support package seemed appropriate for a helper class depending on ServerWebExchange in web.server itself.
The recent refactoring lead to
java.lang.NoClassDefFoundError: io/reactivex/Completable
where only RxJava 1 is in the classpath. Most likely due to the
lack of prefix in Completable::complete with rx package to avoid
the RxJava 2 reference.
Main differences with the Spring MVC original implementation:
- Default redirect HTTP code is 303 See Other since we can assume
all HTTP clients support HTTP 1.1 in 2016
- No more http10Compatible property, use statusCode instead
- By default the redirect is relative to the context path
- A builder allow to set various properties if needed
- In UrlBasedViewResolver, a Function<String, RedirectView>
redirectViewProvider property allows to customize RedirectView
instances in a flexible way
Issue: SPR-14534
Simplify getAdapterFrom/To into a single getAdapter method that looks
for an exact match by type first and then isAssignableFrom.
Also expose shortcut methods in ReactiveAdapter to minimize the need
for access to the ReactiveTypeDescriptor.
Issue: SPR-14902
The ReactiveAdapterRegistry now detects the presence of Reactor. In
practice Reactor is required for the Spring Framework reactive support
and it is expected to be present.
The registry however is now capable of being neutral if Reactor is not
present on the classpath for example where other Spring projects may
not have the same assumptions about Reactor's presence.
Issue: SPR-14902
Collapse ReactiveAdapter hierarchy into a single class that simply
delegates to functions for converting to/from a Publisher.
A private ReactorAdapter extension automaticlaly wraps adapted, "raw"
Publisher's as Flux or Mono depending on the semantics of the target
reactive type.
Issue: SPR-14902
This commit polishes previous one by also accepting
generic types explicitly declared with a class that
extends DataBuffer allowing to write Flux<DefaultDataBuffer>
for example.
Issue: SPR-14952
This modifies the signature of
ReactiveHttpOutputMessage#writeAndFlush(...) in order to
be able to use Flux<Flux<DataBuffer>> objects as arguments of
this method.
Issue: SPR-14952
This commit polishes Kotlin nullable support by reusing
MethodParameter#isOptional() instead of adding a new
MethodParameter#isNullable() method, adds
Kotlin tests and introduces Spring Web Reactive
support.
Issue: SPR-14165
Where `isOptional` is used, also check for `isNullable` i.e.
values are not considered required if they are Kotlin nullables:
- spring-messaging: named value method arguments
- spring-web: named value method arguments
- spring-webmvc: request parts
This means that Kotlin client code no longer has to explicity specify
"required=false" for Kotlin nullables -- this information is inferred
automatically by the framework.
Issue: SPR-14165
In case the filter is also registered to the ERROR dispatcher, the
following happens:
* the filter is executed once for the regular execution
* the filter should be executed a second time when dispatched to error
Since the filter is a `OncePerRequestFilter`, the filter is only
executed once and won't be executed when handling the error.
This can lead to situations like spring-projects/spring-boot#7348
This commit makes this filter a simple `GenericFilterBean`.
Issue: SPR-14891
When processing a "close" notification from the server make an effort
to cancel any outstanding heartbeat but avoid going as far as acquiring
the responseLock since the server itself may already hold a lock of its
own leading to a potential deadlock.
The heartbeat task is now also further protected with an isClosed()
check in case the heartbeat does not get cancelled in a concurrent
scenario.
Issue: SPR-14917
This commit adds a HTTP PATCH operation to the RestTemplate:
patchForObject. As with most operations, there are three variants:
varargs, Map, and URI based.
Issue: SPR-14857
Multi-value async attributes like Flux and Observable in the model
are treated with Collection semantics and resolved to Mono<List<?>>
prior to rendering.
Since https://jira.sonarsource.com/browse/SONARGRADL-30, we can now
safely update to sonarqube plugin v2.2.1.
The protobuf gradle plugin is now deprecated - instead of configuring
the new plugin supported by Google, this commits drops that part of the
gradle build since that proto->java conversion is rarely needed and can
be manually run by any member of the team.
When resolved through the `GzipResourceResolver`, CSS files can be
resolved as their pre-gzipped variant, if a ".gz" file is present in the
configured resource locations.
Such resources are gzipped and thus should not be transformed by
`CssLinkResourceTransformer`s, since rewriting those would need to
uncompress/transform/recompress. This would lead to poorer performances
than resolving plain resources and delegating compression to the
container.
This commit checks for `GzippedResource` instances in
`CssLinkResourceTransformer` and avoids processing them.
Issue: SPR-14773
This commit introduces a new ContentDisposition class designed
to parse and generate Content-Disposition header value as defined
in RFC 2183. It supports the disposition type and the name,
filename (or filename* when encoded according to RFC 5987) and
size parameters.
This new class is usually used thanks to
HttpHeaders#getContentDisposition() and
HttpHeaders#setContentDisposition(ContentDisposition).
Issue: SPR-14408
If the body class is not resolvable from the return type and there is
a body instance we now fall back on the class of the body instance.
Issue: SPR-14877
Prior to this commit, the wrong `HandlerResultHandler` could be
resolved when handling exceptions; this could happen only if the
original handler and exception handler had different signatures:
```
Publisher<String> originalHandler() { ... }
@ExceptionHandler(MyCustomException.class)
ResponseEntity<Mono<String>> handleException() { ... }
```
In that case, the `ResponseBodyResultHandler` would be used when
handling exceptions instead of the `ResponseEntityResultHandler`.
This commit ensures that the `HandlerResult` returned by the exception
handler is used to resolve the `HandlerResultHandler`. The latter will
process the result and use it to write to the HTTP response.
Issue: SPR-14876
This commit adds support for `@ResponseStatus` annotations on reactive
controller methods. `HandlerResultHandler`s implementations now
set the status on the `ServerWebExchange`, if and only if the
invocation of the controller method succeeded.
Issue: SPR-14830
This commits adds a validation check whether the SockJS session type
matches the transport type and rejects requests for which they
don't match.
Issue: SPR-14867
- ScriptedSubscriber has been renamed to Verifier
- The Publisher is passed to create() instead of verify()
- No more need to specify the generic type explicitly
- Version is now sync with reactor-core
Issue: SPR-14800
For SPR-14863 we need to adjust the code generation for OpNE
to use !x.equals(y) rather than x!=y. There are also further
cases in the equalityCheck() code in Operator that were not
being handled in the compilation case (when comparators are
used for example). This latter issue also affects OpEQ.
Rather than add yet more bytecode generation, both OpNE and
OpEQ generateCode() methods have been simplified. The
generated code now delegates to equalityCheck() in Operator
which is exactly what the interpreted case does.
This ensures that the compiled code continues to behave just
like the interpreted case. It ensures changes to the interpreted
case are automatically picked up for the compiled case. It
makes the bytecode generation simpler.
The benefit of compilation of SpEL expressions is to avoid
slow reflective calls - that doesn't apply for a basic
(in)equality test so there is no need to go crazy in bytecode
gen.
Issue: SPR-14863
The method to access the Principal from the ServerWebExchange is now
a Mono<Principal> (rather than Optional<Principal>).
There is also support for Principal as a controller method argument.
Issue: SPR-14680, SPR-14865
This commit adds support for detecting the target WebHandler along with
WebFilters, WebExceptionHandlers, and other spring-web reactive
strategies in an ApplicationContext.
WebReactiveConfigurationSupport has @Bean factory methods for
DispatcherHandler and ResponseStatusExceptionHandler.
WebHttpHandlerBuilder has a static factory method that initializes the
builder from an ApplicationContext. This method is also used in the
DispatcherHandler#toHttpHandler(ApplicationContext) shortcut method.
Issue: SPR-14837
The createBinder method in BindingContext now returns the binder
instance rather than a Mono with the expectation that binder
initialization (e.g. @InitBinder) does not require blocking.
Issue: SPR-14543
HandlerMethodArgumentResolver is a non-blocking contract, however only
implementations that read the request body require blocking.
This commit introduces SyncMethodArgumentResolver as an extension of
the non-blocking contract that allows synchronous implementations to
use synchronous argument resolution.
There is also a SyncInvocableHandlerMethod extension that uses only
sync argument resolvers and allows a synchronous invocation.
Issue: SPR-14543
This commit introduces the `DispatcherServletCustomizer` callback
interface that can be used to customize the `DispatcherServlet` that a
`MockMvc` is using.
Previously, only the `dispatchOptions` flag can be customized. This
commit allows to customize any property of `DispatcherServlet` before it
is initialized.
Issue: SPR-14277
The ServerWebExchange now has a getFormData() method that delegates to
FormHttpMessageReader for the parsing and then caches the result so
it may be used multiples times during request processing.
Issue: SPR-14541
This commit introduces two new `WebClient` methods: `retrieveMono` and
`retrieveFlux`, both of which offer direct access to the response body.
More importantly, these methods publish a WebClientException if the
response status code is in the 4xx or 5xx series.
Issue: SPR-14852
Prior to this commit, when using @EnabledIf or @DisabledIf in Spring's
JUnit Jupiter support, the test's ApplicationContext was always eagerly
loaded, even if the ApplicationContext would never be used (i.e., the
test was disabled). This behavior can lead to undesirable side effects
-- for example, attempting to load an application context that requires
services only available on the CI server when the test is not actually
running on the CI server.
This commit addresses this issue by introducing new boolean
`loadContext` flags in @EnabledIf and @DisabledIf. By default these
flags are set to false which means that the user's test application
context will not be loaded to evaluate the expression. On the contrary,
a dummy application context will be loaded instead, and expressions
will be evaluated against that dummy context. Consequently, if the user
wishes to interact with properties from the Spring Environment or with
beans from the test application context, the `loadContext` must be
explicitly set to true.
In addition, expressions which evaluate to a String must now evaluate
to exactly "true" or "false" (ignoring case and surrounding whitespace).
Issue: SPR-14649
This commit further refines 240f254 to also support java.util.Optional
for synchronized cache access (i.e. when the `sync` attribute on
`@Cacheable` is set to `true`).
Issue: SPR-14853
This commit makes sure that the `unregister` order of registered
application contexts has no incidence on the removal of the LiveBeansView
MBean.
Rather than using the last application context's name to compute the
identity of the MBean to remove, the identity is stored when the MBean is
created.
This commit also adds missing tests.
Issue: SPR-14848
This commit introduces a couple of changes to BodyInserters:
- Refactored writeWithMessageWriters into BiFunction
- BodyInserters.fromResource now uses ResourceMessagewriter from context
- BodyInserters.fromServerSentEvents now uses SseHttpMessageWriter from context
Reactor recently added the `ScriptedSubscriber` in its new
`reactor-addons` module. This `Subscriber` revissits the previous
`TestSubscriber` with many improvements, including:
* scripting each expectation
* builder API that guides you until the final verification step
* virtual time support
This commit refactor all existing tests to use this new
infrastructure and removed the `TestSubscriber` implementation.
Issue: SPR-14800
This commit improves NoSuchBeanDefinitionException to expose a full
ResolvableType rather than a raw class if a lookup by type failed. This
allows to know more about the underlying type and is typically useful
when a collection or map is required as the relevant generic type is the
actual bean that wasn't found.
Issue: SPR-14831
At present Tomcat expects a WriteListener to be registered immediately
on the initial thread so for the time being this commit ensures the
WriteListener is registered unconditionally for every request.
Issue: SPR-14772, SPR-14803
This commit removes factory methods for `RequestMappingHandlerMapping`
and `RequestMappingHandlerAdapter` from `WebReactiveConfigurer`.
`WebReactiveConfigurer` should promote only common customizations;
those factory methods should be overridden when extending
`WebReactiveConfigurationSupport`, in advanced configuration scenarios.
This commit replaces the lazy URI and headers initialization in the
reactive ServerHttpRequest in favor of eager initialization at
construction time. Both the URI and headers are nearly guaranteed to
be accessed for every request (URI for application path, headers for
"Origin" header).
Query params are still lazily parsed but parsing is idemptotent and
in the unlikely case of concurrent access (it's the framework that
typically accesses query params) it maybe parsed twice but should
be side effect free still.
Cookies are also parsed lazily and since we delegate to the "native"
request, it depends on the underlying runtime whether synchronization
is needed. This commit adds synchronization for the HttpServletRequest.
At present RxNetty, Reactor, and Undertow implementations provide
thread-safe access to cookies.
This commit introduces support for running multiple HttpHandler's under
distinct context paths which effectively allows running multiple
applications on the same server. ContextPathIntegrationTests contains
an example of two applications with different context paths.
In order to support this the HttpHandler adapters for all supported
runtimes now have a common base class HttpHandlerAdapterSupport
which has two constructor choices -- one with a single HttpHandler and
another with a Map<String, HttpHandler>.
Note that in addition to the contextPath under which an HttpHandler is
configured there may also be a "native" contextPath under which the
native runtime adapter is configured (e.g. Servlet containers). In such
cases the contextPath is a combination of the native contextPath and
the contextPath assigned to the HttpHandler. See for example
HttpHandlerAdapterSupportTests.
Issue: SPR-14726
This commit adds a bodyToMono and bodyToFlux convenience method to
ClientResponse/ServerRequest, similar to the body(Publisher) method that
is on ClientRequest/ServerResponse.
This commit introduces the following changes to web.reactive.function:
- Added RouterFunction.andRoute(), a combination of RouterFunction.and()
with RouterFunctions.route()
- ServerRequest.pathVariable() returns String instead of
Optional<String>. An exception is thrown if the variable is not present.
- Added HandlerFilterFunction.andThen and HandlerFilterFunction.apply()
This commit removes the usage of Reactor adapters (about to
be moved from Reactor Core to a new Reactor Adapter module).
Instead, RxReactiveStreams is now used for adapting RxJava
1 and Flowable methods are used for RxJava 2.
Issue: SPR-14824
This commit changes web.reactive.function to reflect the introduction of
the new WebClient. Changes include:
- Request -> ServerRequest
- Response -> ServerResponse
- FilterFunction -> HandlerFilterFunction
- StrategiesSupplier -> HandlerStrategies
This commit refactors the web client to be more similar to
web.reactive.function. Changes include:
- Refactor ClientWebRequest to immutable ClientRequest with builder and
support for BodyInserters.
- Introduce ClientResponse which exposes headers, status, and support
for reading from the body with BodyExtractors.
- Removed ResponseErrorHandler, in favor of having a ClientResponse
with "error" status code (i.e. 4xx or 5xx). Also removed
WebClientException and subclasses.
- Refactored WebClientConfig to WebClientStrategies.
- Refactored ClientHttpRequestInterceptor to ExchangeFilterFunction.
- Removed ClientWebRequestPostProcessor in favor of
ExchangeFilterFunction, which allows for asynchronous execution.
Issue: SPR-14827
This commit moves the web.reactive.function.[BodyInserter|BodyExtractor]
to http.codec, so that they can be used from the client as well.
Furthermore, it parameterized both inserter and extractor over
ReactiveHttpOutputMessage and ReactiveHttpInputMessage respectively, so
that they can be limited to only be used on the client or server.
Typically the Mono<Void> from the HttpHandler also reflects the
completion of the request and response body processors and at that
point invoking AsyncContext#complete() from HandlerResultSubscriber
should be sufficient.
This commit explicitly propagates the AsyncListener.onComplete event
to the request and response body processors for added safety.
Technically as mentioned those processors should have completed but
depending on how the controller is written there is a possibility
the body processors may not have completed.
Issue: SPR-14772
ServerWebExchange now has a getPrincipal method and along with that a
ServerWebExchangeDecorator that can be used to wrap the exchange in
order to return the authenticated user.
Issue: SPR-14680
The documentation mentions various NativeJdbcExtractors that no longer
exist. To be specific CommonsDbcpNativeJdbcExtractor and
XAPoolNativeJdbcExtractor no longer exist.
This commit includes the following changes:
* remove CommonsDbcpNativeJdbcExtractor references from Asciidoctor
* remove CommonsDbcpNativeJdbcExtractor references from Javadoc
* remove XAPoolNativeJdbcExtractor references from Asciidoctor
Issue: SPR-14810
Closes gh-1205
String with version 5 the name of Java Platform, Enterprise Edition
changed from J2EE to Java EE. However a lot of the documentation still
uses the term J2EE.
This commit includes the following changes:
* replace J2EE with Java EE where appropriate
This is not a blind search and replace. The following occurrences
remain unchanged:
* references to old J2EE releases, most notably 1.3 and 1.4.
* references to "Expert One-On-One J2EE Design and Development"
* references to "Core J2EE patterns"
* XML namespaces
* package names
Issue: SPR-14811
See gh-1206
This commit improves the existing web reactive configuration
infrastructure with the following changes:
* renamed `WebReactiveConfiguration` to
`WebReactiveConfigurationSupport` and is is no longer a Configuration
class
* created the `WebReactiveConfigurer` interface; Configuration classes
implementing it will augment the web reactive configuration support
* created the `DelegatingWebReactiveConfiguration` and
`WebReactiveConfigurerComposite` to effectively tie those custom-defined
configurers to the main configuration support
* created the `@EnableWebReactive` to active that support in
configuration classes
Issue: SPR-14754
Now that OracleLobHandler has finally been removed it should also be
removed from the documentation.
This commit includes the following changes:
* remove OracleLobHandler references from Javadoc
* remove OracleLobHandler references from Asciidoctor
Issue: SPR-14809
Closes gh-1204
Problem:
The following exception is observed on an async timeout:
"java.lang.IllegalStateException: It is invalid to call
isReady() when the response has not been put into non-blocking mode"
Current Implementation:
The async operation events sent by the web container are not propagated
to the internal implementation. When timeout/error happens and if the
application does not complete the async operation, the web container
will complete it. At that point if the application tries to read/write,
the operation will fail with an exception (above) that there is not
async operation started.
Proposed Solution:
On async timeout or error, make calls to:
- AbstractRequestBodyPublisher.onError,
- AbstractResponseBodyProcessor.onError,
- AbstractResponseBodyFlushProcessor.onError
As a result of these calls the async operation will be completed and no
more invocations of read/write will be made.
This commit simplifies the logic for applying beforeCommit actions
replacing the use of chained Mono.then calls with a single
Flux.concat.
Also renamed writeStatusCode, writeHeaders, and writeCookies to
applyStatusCode, applyHeaders, and applyCookies respectively to
better reflect we're simply setting them on the underlying response
(not necessarily written yet).
Before this change the getHttpEntityType method in
HttpEntityMethodProcessor raised an ISE if the generic type cannot be
detected. That made sense for resolving a controller method argument
where the target body type is crucial. However for a return value
the generic type should not be required since we either have an
actual body or no body at all in which case it doesn't even matter.
This change relaxes the checks and defaults to Object.class for the
ResponseEntity generic type on the return value side.
Issue: SPR-14799
Prior to this commit, the redirectedUrl() and forwardedUrl() methods in
MockMvcResultMatchers supported fully constructed URLs and URLs
containing Ant-style path patterns. However, URI templates were not
supported for these result matchers even though the request path can be
built using URL templates -- for example, via the get() and post()
methods in MockMvcRequestBuilders.
This commit addresses this shortcoming by allowing users to supply a
URL template instead of a fully constructed URL to redirectedUrl() and
forwardedUrl(). To populate the URL template, template variables may be
supplied to redirectedUrl() and forwardedUrl() as var-args.
Issue: SPR-14790
Commit e65a1a4372 introduced support in PrintingResultHandler for only
printing the request or response body in the Spring MVC Test framework
if the content type is known to be text-based (e.g., plain text, HTML,
XHTML, XML, JSON, etc.). For unknown content types the body is assumed
to be text-based and is therefore always printed. The latter behavior,
however, is undesirable since the content may in fact not be text-based.
This commit addresses this issue by making the printing of the request
or response body an opt-in feature. Specifically, if a character
encoding has been set, the request or response body will be printed by
the PrintingResultHandler. Note, however, that the character encoding
is set to ISO-8859-1 in MockHttpServletResponse by default.
In addition, MockHttpServletRequest's getContentAsString() method now
throws an IllegalStateException if the character encoding has not been
set.
Issue: SPR-14776
This commit replaces direct use of Validator and ConversionService in
the reactive @RequestMapping infrustructure in favor of using the
BindingContext.
Issue: SPR-14541
This commit adds a BindingContext to be used in spring-web-reactive
@RequestMapping infrastructure (comparable to WebDataBinderFactory in
spring-web-mvc) for access to the default model, data binding,
validation, and type conversion purposes.
Issue: SPR-14541
Prior to this commit, PrintingResultHandler always printed the request
or response body regardless of its content type. For binary content,
however, the output was unreadable and therefore useless.
This commit addresses this issue by only printing the request or
response body if it is "printable" (i.e., if its content type is known
to be text-based such as plain text, HTML, XHTML, XML, JSON, etc.). If
the content type is unknown (e.g., unspecified for the HTTP request in
the test), it is assumed that the body is printable.
Issue: SPR-14776
Prior to this commit, `ResourceTransformer` implementations would
resolve internal links to other resources: both relative and absolute
request paths.
For relative request paths, those transformers would call
`ResourceTransformerSupport.resolveUrlPath` with the resource path,
as provided in the original file. This can cause problems when a
`CachingResourceResolver` is configured in the resolver chain, because
this resolver is caching resources, deriving the cache key from the
given resource path — this can cause collisions for cases like this:
resources/
|--foo/
| |--foo.css (imports style.css)
| |--style.css
|--bar/
| |--bar.css (imports style.css)
| |--style.css
The first "style.css" resolved resource is then cached and will be given
to any request asking for "style.css".
To avoid those issues, this commit improves the `ResourceTransformer`
implementations to calculate the absolute request path before asking the
chain to resolve the resource URL, thus avoiding duplications.
The resource chain will be then asked to resolve "/foo/style/css" or
"/bar/style.css".
Issue: SPR-14597
This is a port of Spring MVC CORS support for Spring Web Reactive:
- CORS classes keep the same name but are in the
web.cors.reactive package
- CorsConfiguration is reused because not tied to Servlet API
- CORS HandlerMapping integration is done at
AbstractHandlerMapping level
- AbstractUrlHandlerMapping and AbstractHandlerMethodMapping
have been slightly modified to call
AbstractHandlerMapping#processCorsRequest()
- Both global CORS configuration + @CrossOrigin support have
been implemented
Issue: SPR-14545
This commit configures a default SslContext if none has been provided.
This also enforces separate Netty bootstrap instances for cleartext and
TLS exchanges.
Issue: SPR-14744
Prior to this commit, the `HttpEntityMethodProcessor` would avoid
writing ETag/Last-Modified response headers before calling
`ServletWebRequest` to process conditional requests. This was done to
avoid duplicate response header values due to headers being already
written to the underlying servlet response.
This is still necessary for GET/HEAD requests, since this is properly
handled by `ServletWebRequest` for those cases. But
`HttpEntityMethodProcessor` should not make that decision for
PUT/PATCH/POST responses since developers are adding response headers on
purpose and should be in control of the situation — whereas
`ServletWebRequest` does not write those headers in those cases.
Issue: SPR-14767
Prior to this commit, the PrintingResultHandler used by the various
print() and log() methods in Spring MVC Test printed the response body
but not the request body.
Since request bodies are sometimes generated programmatically, however,
it can be beneficial to have the dynamically generated request body
logged as well.
This commit therefore prints the request body in PrintingResultHandler
by delegating to the recently introduced getContentAsString() method in
MockHttpServletRequest.
Issue: SPR-14717
In order to improve debugging and logging within test suites, this
commit introduces getContentAsByteArray() and getContentAsString()
methods in MockHttpServletRequest, analogous to the existing methods in
MockHttpServletResponse.
Issue: SPR-14717
This commit adds a new chain-based, interception contract to be used
with `WebClient`. This is the HTTP client equivalent of the `WebFilter`
contract already implemented in web reactive server.
A `ClientHttpRequestInterceptor` implementation can transform the
outgoing HTTP request (method, URI or headers) before delegating it to
the next interceptor in the chain, or bypass the request processing
altogether and return a (cached) HTTP response.
Issue: SPR-14502
This commit handles range requests in `ResourceWebHandler`, using the
`ResourceHttpMessageWriter` configured within the handler.
This `WebHandler` will add a `HTTP_RANGE_REQUEST_HINT` writer hint
containing all the HTTP Range information of the request.
Issue: SPR-14664
This new `HttpMessageWriter` leverages the `ResourceRegionEncoder` to
write `ResourceRegion` to HTTP responses, thus supporting HTTP Range
requests.
Whenever possible, this message writer uses the zero copy support for
single range requests.
This `HttpMessageWriter` is never used directly, but is used as a
delegate by the `ResourceHttpMessageWriter`. When provided with the
`BOUNDARY_STRING_HINT`, the `ResourceRegionHttpMessageWriter`
adapts its behavior in order to write a single/multiple byte ranges.
Issue: SPR-14664
This commit adds the necessary infrastructure for the support of HTTP
Range requests. The new `ResourceRegionEncoder` can write
`ResourceRegion` objects as streams of bytes.
The `ResourceRegionEncoder` relies on an encoding hint
`BOUNDARY_STRING_HINT`. If present, the encoder infers that multiple
`ResourceRegion`s should be encoded and that the provided boundary
String should be used to separate ranges by mime boundaries.
If that hint is absent, only a single resource region is encoded.
Issue: SPR-14664
This commit makes it possible, in addition to provide hints, to
perform additional operations with the request and the response
at ServerHttpMessageReader/Writer level.
AbstractServerHttpMessageReader/Writer now provide
convenient beforeRead/beforeWrite abstract methods for such need.
Issue: SPR-14557
Resetting the connection first before invoking a failure callback on
the application handler ensures that any checks to isConnected will
return false.
Issue: SPR-14721
This commit overrides the `checkResource` implementation in
`ScriptTemplateView` in order to check if the template file resource is
available and if the resolver can then proceed with rendering the
template.
Issue: SPR-14729
Cherry-picked from: 66b370e10
In order to simplify configuration for use cases involving @Bean where
only a bean name or aliases are supplied as an attribute, this commit
introduces a new 'value' attribute that is an @AliasFor 'name' in @Bean.
Issue: SPR-14728
Move the AbstractServletHttpHandlerAdapterInitializer together with
the other two base classes in spring-web-reactive. Since the
interface is in the web package, this avoids a package cycle.
Also add a mention in the reference.
Issue: SPR-14713
This commit introduces three new WebApplicationInitializers for use with
Spring Web Reactive:
- The AbstractServletHttpHandlerAdapterInitializer registers a
ServletHttpHandlerAdapter that wraps a user-provided HttpHandler.
- The AbstractDispatcherHandlerInitializer registers a
ServletHttpHandlerAdapter that wraps a DispatcherHandler (or any
WebHandler). The handler is provided with an application context.
- The AbstractAnnotationConfigDispatcherHandlerInitializer is a
subclass of the above, creating an
AnnotationConfigApplicationContext based no provided @Configuration
classes.
Issue: SPR-14713
This commit extracts the response body insertion logic into a separate
strategy interface: BodyPopulator. Standard populators can be found in
BodyPopulators.
This commit refactors the Router into a RoutingFunctions class, by:
- Renaming the class :)
- Moving all Configuration logic into a separate, top-level
Configuration class with mutable builder.
Since appcache manifests can have various file extensions, developers
should register the (file extension, media type) mapping in their Spring
MVC / Reactive Web configuration.
This commit adds javadoc on both `AppCacheManifestTransformer` variants
to explain how to do that.
Issue: SPR-14510
Improve RootBeanDefinition to specify an AnnotatedElement that holds
qualifier information. When such element is present, any qualifier that
it defines will be used to find a matching candidate.
Issue: SPR-14725
Rather than setting the status to 503 directly from the timeout
interceptor which no longer seems to work reliably with Servlet
containers like Jetty even performing an additional ERROR dispatch back
to the original URL, we know rather set the DeferredResult to an
AsyncTimeoutException, which results in a dispatch and standard
handling within Spring MVC. This should be a more reliable way of
dealing with timeouts.
Issue: SPR-14669
Added readableChannel() to Resource, which returns a
java.nio.ReadableByteChannel. The default implementation uses
Channels.newChannel() to create a channel based on what is returned from
getInputStream(). Subclasses have more effecient, file-based
implementations.
Issue: SPR-14698
Fixed bug where the returned Flux from DataBufferUtils.read() would be
completed prematurely if the channel was not ready to read, but did
not reach the end of the file either.
This commit changes the default file extension configured with
`AppCacheManifestTranformer`. This ResourceTransformer was previously
considering `.manifest` files by default, but this has been changed in
the official spec to `appcache`, in order not to clash with Microsoft's
unregistered application/manifest type.
Issue: SPR-14687
`ResolvedResource` is a rather generic name - changing the extended
interface to something more meaningful: `HttpResource`.
For now, implementations are linked with the resource handling chain,
but this aspect has been removed from the interface documentation.
Issue: SPR-14264
Prior to this commit, FreeMarkerView used the system default charset to
render. This commit switches this by defaulting to UTF-8, if no charset
is specified in the content type.
- Add contentType parameter to AbstractView.renderInternal, used to
determine the charset contained therein
- Adds a defaultCharset property to AbstractView and
ViewResolverSupport.
Changed View's render method from taking a HandlerResult to taking a
Map<String, ?>, in order to facilitate scenarios where a HandlerResult
is not available (i.e. web.reactive.function).
Two changes to web.reactive.function:
- Changed Response.stream method to allow for specific Publisher types
to be returned in Response.
- Router now stores HttpMessageReader|Writer retrieved from
Configuration in the attributes as supplier, not as stream, to allow
for multiple reads.
Prior to this commit, the resource handling chain and its
`ResourceResolvers` would use specific `Resource` implementations in
order to add resource metadata to the HTTP response. For example,
`VersionedResource` and `EncodedResource` are both adding specific HTTP
response headers.
This commit aims at making this mechanism more stable and reusable,
since the previous implementation would fail in case a resolved resource
would be both a `VersionedResource` wrapping a `EncodedResource` (or the
other way arount). Only one of the specific implementations would
contribute its metadata since the code supporting that in
`ResourceHttpRequestHandler` would only check for `instanceof` tests,
whereas those implementations are acutally delegating calls to
the wrapped resource.
Now both `VersionedResource` and `EncodedResource` have been replaced by
specific implementations of `ResolvedResource`, which directly provides
those HTTP response headers as part of `getResponseHeaders()`.
This commit applies the same changes for the web reactive
implementations and its `ResourceWebHandler`.
Issue: SPR-14264
Since SPR-14522, the web reactive framework supports checkNotModified
features. This commit aligns the existing MVC infrastructure with
web reactive's behavior.
Because of the new Servlet 3.0 baseline, some constraints
aren't relevant anymore and duplicate code has been removed in
`HttpEntityMethodProcessor`.
Issue: SPR-14659
A straight-forward port of the resource handling support in
spring-webmvc to spring-web-reactive. Primarily adapting contracts and
implementations to use the reactive request and response and the
reactive ResourceHttpMessageWriter.
Issue: SPR-14521
Whereas the existing TestContextConcurrencyTests verify support for
concurrency in the TestContextManager and TestContext, this commit
introduces SpringJUnit4ConcurrencyTests that verify support for
concurrent test execution in Spring's JUnit 4 support, namely in the
SpringRunner, SpringClassRule, and SpringMethodRule.
The tests executed by this new test class come from a hand-picked
collection of test classes within the test suite that is intended to
cover most categories of tests that are currently supported by the
TestContext Framework on JUnit 4.
Note, however, that the chosen test classes intentionally do not
include any classes that fall under the following categories.
- tests that make use of Spring's @DirtiesContext support
- tests that make use of JUnit 4's @FixMethodOrder support
- tests that commit changes to the state of a shared in-memory database
Issue: SPR-5863
This commit improves the exception message thrown when a test's
ApplicationContext is no longer active by explaining that the cause
may be due to parallel test execution.
Issue: SPR-5863
As per specification "The Subscription MUST allow the Subscriber to
call Subscription.request synchronously from within onNext or
onSubscribe". With the current implementation if Subscription.request
is called more than once when Subscriber.onSubscribe ISE will be
thrown - java.lang.IllegalStateException: DEMAND.
With this fix the implementation will not throw ISE and will allow
many invocations of Subscription.request when
Subscriber.onSubscribe.
This commit fixes `ResponseEntityResultHandler` so that it only tries to
call `writeBody` if the `ResponseEntity` is not null. In case the
response entity body is null, the response is flushed right away and the
request is signaled as handled.
Issue: SPR-14663
Prior to this commit, executing tests concurrently in the TestContext
Framework (TCF) was unsupported and typically lead to unpredictable
results.
This commit addresses this core issue by supporting concurrent
execution in the TestContextManager and the DefaultTestContext.
Specifically, the TestContextManager now uses ThreadLocal storage for
the current TestContext, thereby ensuring that any registered
TestExecutionListeners and the TestContextManager itself operate on a
TestContext specific to the current thread.
In order to avoid repeatedly incurring the costs of the overhead of the
TCF bootstrapping process, the original TestContext built by the
TestContextBootstrapper is used as a template which is then passed to
the copy constructor of the concrete implementation of the TestContext
to create the context for the current thread. DefaultTestContext now
implements such a copy constructor, and all concrete implementations of
TestContext are encouraged to do the same.
If the TestContext built by the TestContextBootstrapper does not
provide a copy constructor, thread-safety and support for concurrency
are left completely to the implementation of the concrete TestContext.
Note, however, that this commit does not address any thread-safety or
concurrency issues in the ContextLoader SPI or its implementations.
Issue: SPR-5863
This commit inlines the basic implementation of AttributeAccessorSupport
and converts the LinkedHashMap to a ConcurrentHashMap.
In addition, attributes are now included in toString().
Issue: SPR-5863
This change puts the MockHttpServerRequest/Response under
org.springframework.mock.http.server.reactive.test which
mirrors the arrangement we have with the Servlet mock equivalents
and sets up the addition of MockHttpServerRequest/Response in
spring-test.
Issue: SPR-14421
This commit documents the regexp support in `AntPathMatcher` when
matching for URL patterns. This support is also mentioned in places
where developers can register patterns for ViewControllers or resource
handlers.
Issue: SPR-14652
This commit avoid merging automatically the SSE stream with
Flux.never(). Since browsers automatically reconnect when
the HTTP connection is closed, it is now the user responsability
to optionally perform a concatWith(Flux.never()) on streams that
complete in order to avoid receiving the data multiple times on
client side.
The behavior with hot streams that never complete does not change.
Issue: SPR-14578
This commit adds a "spring-context-indexer" module that can be added to
any project in order to generate an index of candidate components defined
in the project.
`CandidateComponentsIndexer` is a standard annotation processor that
looks for source files with target annotations (typically `@Component`)
and references them in a `META-INF/spring.components` generated file.
Each entry in the index is the fully qualified name of a candidate
component and the comma-separated list of stereotypes that apply to that
candidate. A typical example of a stereotype is `@Component`. If a
project has a `com.example.FooService` annotated with `@Component` the
following `META-INF/spring.components` file is generated at compile time:
```
com.example.FooService=org.springframework.stereotype.Component
```
A new `@Indexed` annotation can be added on any annotation to instructs
the scanner to include a source file that contains that annotation. For
instance, `@Component` is meta-annotated with `@Indexed` now and adding
`@Indexed` to more annotation types will transparently improve the index
with additional information. This also works for interaces or parent
classes: adding `@Indexed` on a `Repository` base interface means that
the indexed can be queried for its implementation by using the fully
qualified name of the `Repository` interface.
The indexer also adds any class or interface that has a type-level
annotation from the `javax` package. This includes obviously JPA
(`@Entity` and related) but also CDI (`@Named`, `@ManagedBean`) and
servlet annotations (i.e. `@WebFilter`). These are meant to handle
cases where a component needs to identify candidates and use classpath
scanning currently.
If a `package-info.java` file exists, the package is registered using
a "package-info" stereotype.
Such files can later be reused by the `ApplicationContext` to avoid
using component scan. A global `CandidateComponentsIndex` can be easily
loaded from the current classpath using `CandidateComponentsIndexLoader`.
The core framework uses such infrastructure in two areas: to retrieve
the candidate `@Component`s and to build a default `PersistenceUnitInfo`.
Rather than scanning the classpath and using ASM to identify candidates,
the index is used if present.
As long as the include filters refer to an annotation that is directly
annotated with `@Indexed` or an assignable type that is directly
annotated with `@Indexed`, the index can be used since a dedicated entry
wil be present for that type. If any other unsupported include filter is
specified, we fallback on classpath scanning.
In case the index is incomplete or cannot be used, The
`spring.index.ignore` system property can be set to `true` or,
alternatively, in a "spring.properties" at the root of the classpath.
Issue: SPR-11890
This commit introduces a new, functional web programming model in the
org.springframework.web.reactive.function package. The key types
are:
- Request and Response are new Java 8-DSLs for access to the HTTP
request and response
- HandlerFunction represents a function to handle a request to a
response
- RoutingFunction maps a request to a HandlerFunction
- FilterFunction filters a routing as defined by a RoutingFunction
- RequestPredicate is used by Router to create RoutingFunctions
- RequestPredicates offers common RequestPredicate instances
- Renamed SseEvent to ServerSentEvent to make the name less redundant.
- ServerSentEvent is now immutable, having a builder to create new instances.
- Realigned the class properties to more closely match the events
described in the spec, so that `reconnectTime` becomes `retry`, and
`name` becomes `event`.
This commit introduces integration tests that verify the expected
behavior for @Nested tests in conjunction with the SpringExtension for
JUnit Jupiter, including automatic application of
TestExecutionListeners to the enclosing test instance of a @Nested
test instance.
Issue: SPR-14150
Due to restrictions imposed by JUnit 4, the SpringClassRule must be
declared as a public static field, which makes it impossible to be
declared directly within a nested (i.e., inner) test class.
This commit demonstrates a work-around that makes it possible to use
the SpringClassRule and SpringMethodRule in a nested (i.e., inner) test
class when using a custom JUnit 4 runner such as the
HierarchicalContextRunner from Stefan Bechtold.
The trick is to have inner test classes extend a class that properly
declares the SpringClassRule and SpringMethodRule. The
SpringRuleConfigurer in this commit serves as an example.
Note, however, that each such nested test class must declare its own
@ContextConfiguration. Furthermore, TestExecutionListeners in the
Spring TestContext Framework are not applied to the enclosing instance
of such an inner test class, meaning that @Autowired fields in the
enclosing instance will not be injected, etc.
Issue: SPR-14150
A little terminiology first:
* merge.from - a project that contains source that will be merged
into merge.into
* merge.into - a project that contains source code that will have
code from merge.from merged into it.
Previously a module that dependended on merge.into would not see
the merge.from module as a transitive dependency. This worked fine
from a Gradle build because all the code from merge.from is merged
into the merge.into jar. However, in an IDE it did not work because
the IDE does not assemble a jar.
This fix ensures that merge.from modules are automatically added
to the classpath of any module relying on the merge.into project.
Fixes SPR-14650
This commit picks up where SPR-14614 left off by introducing a new
@EnabledIf annotation to serve as a logical companion to @DisabledIf.
In addition, this commit extracts common logic from DisabledIfCondition
into a new AbstractExpressionEvaluatingCondition base class which the
new EnabledIfCondition also extends.
An @EnabledOnMac annotation is also included in the Javadoc as well as
in the test suite to demonstrate support for custom composed annotations.
Issue: SPR-14644
This commit updates the instructions on getting started with
Spring Web Reactive and also updates constructors and setters to
streamline the getting started procedure.
Issue: SPR-14640
This is a follow-up on commit 3b95e0b relaxing the expectation that a
ServletContext is present. Instead we check defensively and fall back
on PathExtensionContentNegotiationStrategy which can use JAF.
Issue: SPR-14577
Create an explicit heartbeat task with an experiration flag so that
it can be cancelled reliably vs relying on the ScheduledFutureTask
cancel method which may return true even if the task is already
running.
Issue: SPR-14356
Prior to this commit, exceptions thrown by the
`HandlerMethodArgumentResolver` would be wrapped into
`IllegalStateException`s.
This commit makes sure that a DEBUG log is written with the relevant
information and that the root cause is not wrapped into another
exception, so that the appropriate `ExceptionHandler` can be used to
deal with this error.
Issue: SPR-14618
This commit adds Smile and CBOR Jackson HttpMessageConverters
and make it possible to create Smile and CBOR ObjectMapper via
Jackson2ObjectMapperBuilder, which now allows to specify any
custom JsonFactory.
Like with JSON and XML Jackson support, the relevant
HttpMessageConverters are automaticially configurered by
Spring MVC WebMvcConfigurationSupport if jackson-dataformat-smile
or jackson-dataformat-cbor dependencies are found in the classpath.
Issue: SPR-14435
Prior to this commit, the DisabledIfCondition did not trim whitespace
from expressions configured via @DisabledIf. Consequently, results such
as " true " would evaluate to "false".
This commit fixes this problem by trimming all expressions configured
via @DisabledIf.
Issue: SPR-14614
This commit introduces tests for DisabledIfCondition that verify actual
condition evaluation results and exception handling; whereas, the
existing tests in DisabledIfTestCase only test the "happy paths" and
standard cases.
Issue: SPR-14614
- Extracted stand-alone DisabledIfCondition from the SpringExtension
so that the condition is only evaluated when necessary.
- Simplified implementation of DisabledIfCondition.
- Overhauled and extended logging in DisabledIfCondition.
- DisabledIfCondition now throws an IllegalStateException if @DisabledIf
is not present on the test element or if the expression does not
evaluate to a String or Boolean.
- Each generated ConditionEvaluationResult now includes the actual
expression in the default reason.
- @DisabledIf is now auto-configured to be evaluated by the
DisabledIfCondition since it is now meta-annotated with
@ExtendWith(DisabledIfCondition.class)
- Overhauled documentation for @DisabledIf and provided standard
examples as well as an @DisabledOnMac annotation to demonstrate
support for custom composed annotations.
Issue: SPR-14614
This commit introduces @DisabledIf annotation that takes SpEL as a
condition. The condition is evaluated at run time whether to disable
JUnit 5 (Jupiter) test method/class.
Issue: SPR-14614
When using a `RestTemplate` instance within a Spring MVC application,
client exceptions may propagate in the MVC stack and can be wrongly
mapped by server `ExceptionHandlers`, leading to a wrong HTTP response
sent to the MVC client.
The `RestTemplate` instance uses `HttpMessageConverter` to decode
the remote service responses; and when those fail decoding an HTTP
response, they can throw an `HttpMessageNotReadableException`. That
exception then bubbles up through the `HttpMessageConverterExtractor`,
`RestTemplate` and the whole MVC stack, later mapped to HTTP 400
responses, since those exceptions can also be throws by the server stack
when the incoming requests can't be deserialized.
This commit wraps all `IOException` and `HttpMessageNotReadableException`
instances thrown by the extractor into `RestClientException`` instances.
It's now easier to consistently handle client exceptions and avoid such
edge cases.
Issue: SPR-13592
This change adds support for a target type in JsonPath assertions in
Spring MVC Test.
The existing assertValue(String expression, Object expectedValue)
transparently falls back on using an alternative JsonPath API that
allows specifying the target type to coerce to.
There is also a new overloaded method
assertValue(String expression, Matcher<T> matcher, Class<T> targetType)
for use with Hamcrest matchers where the target type can be specified.
Issue: SPR-14498
HttpEntityMethodProcessor should not throw IllegalArgumentExceptions for
invalid If-None-Match headers.
For those cases, this commit makes sure that both
`HttpEntityMethodProcessor` and `ServletWebRequest` have a consistent
behavior and stop processing the request as conditional and leave the
handler handle it.
Issue: SPR-14559
This commit sorts `ClientHttpRequestInterceptor`s when those are set in
`InterceptingHttpAccessor` (which `RestTemplate` extends from).
Interceptors can now be annotated with `@Order` or implements `Ordered`
to reflect their order of execution for each request.
Issue: SPR-13971
This commit adds support for HTTP header field parameters encoding, as
described in RFC5987.
Note that the default implementation still relies on US-ASCII encoding,
as the latest rfc7230 Section 3.2.4 says that:
> Newly defined header fields SHOULD limit their field values to
US-ASCII octets
Issue: SPR-14547
Prior to this commit, extracting an HTTP response with an empty body
and no Content-Type header using the WebClient would:
* trigger the use of the Jackson2JsonDecoder
* throw a NoSuchElementException because of the use of `Flux.single()`
This commit changes this behavior to `Flux.singleOrEmpty()` to avoid
throwing exceptions for empty Flux instances.
Issue: SPR-14582
Since the upgrade to Gradle 3, our Bamboo build is failing because it
can't find test reports "at the usual location".
This commit restores the location that Gradle 2 was using until we
upgrade to a version of Bamboo that supports it.
Issue: SPR-14569
Previously the IDE (STS) was resolving a different reactor-core
version (3.0.0.BUILD-SNAPSHOT) than the build (3.0.0.RELEASE). This
discrepancy was due to the fact that reactor-netty now brings in
reactor-core 3.0.0.RELEASE. Gradle's version conflict resolution is to use
the latest version. However, the optional dependency on reactor-core
3.0.0.BUILD-SNAPSHOT was making the build path of the IDE use the SNAPSHOT.
This fix leverages a resolutionStrategy to ensure a consistent version of
reactor-core is used throughout the entire project. It also bumps up the
reactor-core version to 3.0.0.RELEASE to be consistent with reactor-netty.
Care is taken to only change 3.x vesion since 2.x is still used within
the codebase.
Since we have a dedicated section regarding Ehcache that is only
applicable to Ehcache 2.x, this commit clarifies that Ehcache 3.x is
JSR-107 compliant and the JCache support should be used with it
rather than attempting to configure the Ehcache 2.x support.
Commit 240f254 has introduced support for `java.util.Optional` in the
cache abstraction. If such type is present, the contained value is cached
if it is present.
This new feature slightly changed the semantic of `#result` that was
documented up till this commit as the "return value of the method
invocation". This is no longer true as `#result` for `Optional<T>`
refers to the `T` instance and not the `Optional` instance.
This commit clarifies both the javadoc and the documentation.
Issue: SPR-14587
Previously invoking HtmlUnitRequestBuilder merge caused the pathInfo of
the parent to be corrupted. This could additional invocations with the
same parent.
This fix ensures that the parent is no longer directly used. Instead,
we create a copy of the parent by merging the parent that was passed in
with the copy.
Fixes SPR-14584
reactor.test.TestSubscriber will not be part of Reactor Core
3.0.0 since it needs to be refactored to fit all the needs
expressed by the users. It is likely to be back later in one
of the Reactor Core 3.0.x releases.
This commit anticipate this removal by temporarily copying
TestSubscriber in spring-core test classes. As soon as
the new TestSubscriber will be available in Reactor Core,
Spring Framework reactive tests will use it again.
There is really no need for a result handler dedicated to a void
return value and it's actually problematic to have it.
Each result handler treats void as necessary. For an @ResponseBody
method it means an empty body. For view resolution it means no specific
value was returned and we should procede with selecting a default view
name. Having a dedicated void result handler can interfere with this
especially since view resolution needs to be last in order.
At the same time there are cases when no result handling is needed
and the response is fully handled within the HandlerAdapter. This is
the case with WebHandler and the SimpleHandlerAdapter. For that case
we simply return mono.then(aVoid -> Mono.empty()) which effectively
returns an empty Mono and no result handling follows. The
HandlerAdapter already says you can return no values at all if the
response is fully handled.
With the current state machine
- the implementation can hang after the last element when executing
on Jetty.
- in some cases there will be no flush after the last
Publisher<DataBuffer>.
AbstractResponseBodyProcessor.onError and
AbstractResponseBodyFlushProcessor.onError will be invoked when:
- The Publisher wants to signal with onError that there are failures.
Once onError is invoked the Subscription should be considered canceled.
- The internal implementation wants to signal with onError that there
are failures. In this use case the implementation should invoke
Subscription.cancel()
DataSourceUtils moved to main core.io.buffer package.
Consistently named Jackson2JsonDecoder/Encoder and Jaxb2XmlDecoder/Encoder.
Plenty of related polishing.
Hibernate 5.2's HibernateException extends PersistenceException, leading to a different constructor compiled into the bytecode, breaking compatibility with Hibernate 5.0 at runtime.
Issue: SPR-13827
xmlunit 2.1.0 is the latest release for xmlunit.
Most of the xmlunit functionality used within spring-framework
was done through the xmlunit 1.x helper class
`org.custommonkey.xmlunit.XMLAssert`.
As of xmlunit 2.0.0 most of the XML comparison methods are done
through hamcrest matchers exposed by the xmlunit-matchers
library. In some cases during the migration, the matchers
had to be customized with custom `NodeMatcher` or
`DifferenceEvaluator` instances in order to keep the assertions
correct (they were performed with xmlunit 1.x previously).
Issue: SPR-14043
This commit adds support for Google Protobuf 3.0.0 and make some changes
in the additional formats support:
* "com.googlecode.protobuf-java-format:protobuf-java-format" is no
longer required and its required version has been raised to 1.3+
(this lib adds support for JSON, XML, HTML formats)
* "com.google.protobuf:protobuf-java-util" is also now supported for
JSON format
Issue: SPR-13589
This commit changes the reactive flushing mechanism to use a newly
introduced writeAndFlushWith(Publisher<Publisher<DataBuffer>>) on
ReactiveHttpOutputMessage instead of using the FlushingDataBuffer.
Issue: https://github.com/spring-projects/spring-reactive/issues/125
This commit ensures that a valid port is given to the underlying Netty
client when no port is defined in the URL itself.
By default, port 80 is used by the Reactor Netty client.
Issue: SPR-14477
The `WebClient` has a new exception hierarchy:
* `WebClientException` is the root of all exceptions thrown by the
`WebClient`
* `WebClientResponseException` are all exceptions associated with
specific HTTP response status codes
* `WebClientErrorException` and `WebServerErrorException` are
respectively for 4xx and 5xx HTTP status codes
`ResponseExtractor` implementations are adapted to optionally throw
exceptions if it's impossible to extract the relevant parts of the
response (e.g. extracting the response body if the response is a 404).
This commit also introduces `ResponseErrorHandler`s that take care of
the whole exception mapping infrastructure. Since
`WebClientResponseException`s provide the status, headers and response
body, we also need a dedicated mechanism to extract information from the
response body at that level.
The `BodyExtractors` are responsible for extracting that information
from the exception, given they are provided with all the information
they need; in that case, message decoders are required.
To convey all this new information downstream, the `WebClient` now wraps
the message converters and response error handler instances into a
dedicated `WebClientConfig` object.
- Added Woodstox before Aalto in the spring-web build, so that Woodstox
is used as StAX implementation, and not the less featured Aalto.
- Hardcoded Aalto dependency in XmlEventDecoder, instead of relying on
the StAX XMLInputFactory.
Prior to this commit, a dynamic test in
FailingBeforeAndAfterMethodsSpringExtensionTestCase was failing but for
the wrong reason. Namely, the @Configuration class was private which
resulted in an IllegalStateException being thrown, when in fact
an AssertionFailedError was expected.
This commit addresses this by introducing an explicit check for an
AssertionFailedError.
Issue: SPR-4365
Prior to this commit, if multiple TestExecutionListener 'after' methods
threw an exception, only the first such exception was rethrown.
Subsequent exceptions were logged, but there was no way to access or
process them other than via the log file.
This commit addresses this shortcoming by making use of the support for
suppressed exceptions introduced in Java 7. Specifically, if multiple
TestExecutionListener 'after' methods throw an exception, the first
exception will be rethrown with subsequent exceptions suppressed in the
first one.
Issue: SPR-14459
Moved ResponseBodyProcessor creation from constructor to
writeWithInternal(), in preparation of supporting both
Publisher<DataBuffer> as well as Publisher<Publisher<DataBuffer>>.
In preparation of supporting both Publisher<DataBuffer> and
Publisher<Publisher<DataBuffer>> as response body, moved
RequestBodyPublisher and ResponseBodyProcessor into
ServletServerHttpRequest and ServletServerHttpResponse respectively.
This commit makes use of the new Supplier<String> variants of utility
methods in org.springframework.util.Assert within the spring-test
module.
Issue: SPR-14450
This commit makes use of the new Supplier<String> variants of utility
methods in org.springframework.util.Assert within the spring-core
module.
Issue: SPR-14450
Prior to this commit, utility methods in
org.springframework.util.Assert accepted String arguments for custom
error messages. Such Strings are evaluated (e.g., concatenated)
eagerly, and for performance reasons, it was therefore not always
possible to make use of these utility methods. Consequently, there are
several places in the code base that "inline" identical functionality
in order to lazily evaluate error message concatenation and avoid an
unnecessary performance penalty. This leads to verbose code like the
following.
if (!contextPath.startsWith("/")) {
throw new IllegalArgumentException("contextPath '" + contextPath +
"' must start with '/'.");
}
if (contextPath.endsWith("/")) {
throw new IllegalArgumentException("contextPath '" + contextPath +
"' must not end with '/'.");
}
This commit addresses this shortcoming by introducing Supplier<String>
variants of all utility methods in org.springframework.util.Assert that
allow custom error messages to be evaluated lazily via a lambda
expression that is only evaluated if the assertion fails. This results
in a simplification of the previous examples as follows.
Assert.isTrue(contextPath.startsWith("/"), () -> "contextPath '" +
contextPath + "' must start with '/'.");
Assert.isTrue(!contextPath.endsWith("/"), () -> "contextPath '" +
contextPath + "' must not end with '/'.");
Issue: SPR-14450
This commit introduces 'before' and 'after' test execution callbacks in
the Spring TestContext Framework. Specifically, this set of commits
introduces the following.
- beforeTestExecution() and afterTestExecution() callbacks in the
TestExecutionListener API
- beforeTestExecution() and afterTestExecution() callbacks in
TestContextManager
- RunBeforeTestExecutionCallbacks and RunAfterTestExecutionCallbacks
JUnit 4 statements that are used by the SpringJUnit4ClassRunner
- Documentation in the class-level Javadoc for SpringMethodRule stating
that before/after test execution callbacks cannot be supported with
JUnit 4 Rules
- Support for JUnit Jupiter's BeforeTestExecutionCallback and
AfterTestExecutionCallback extension APIs in the SpringExtension for
JUnit 5
- Support for before/after test execution callbacks in
AbstractTestNGSpringContextTests for TestNG
Issue: SPR-4365
This commit replaces the current helper methods in
RequestMappingIntegrationTests with generic helper methods to perform
HTTP GET and POST requests.
This results in more transparent code that shows the exact HTTP
inputs and outputs and is also more flexible to change for
variations in testing.
This commit adds the required infrastructure to build HTTP requests as
well as extracting relevant information from HTTP responses using the
RxJava 1.x API, where Observable and Single don't extend Publisher.
This commit refactors the `ClientHttpRequestFactory` into an
`ClientHttpConnector` abstraction, in order to reflect that
`ClientHttpRequest`s only "exist" once the client is connected
to the origin server.
This is why the HTTP client is now callback-based, containing all
interactions with the request within a
`Function<ClientHttpRequest,Mono<Void>>` that signals when it's done
writing to the request.
The `ClientHttpRequest` contract also adopts `setComplete()`
and promotes that method to the `ReactiveHttpOutputMessage` contract.
This commit also adapts all other APIs to that change and fixes a few
issues, including:
* use `HttpMessageConverter`s instead of `Encoders`/`Decoders`
* better handle type information about request content publishers
* support client cookies in HTTP requests
* temporarily remove the RxNetty client support
Reactor's `DependencyUtils` has been renamed to `Converters` and
all the `from` converter methods have been disambiguated to
`fromPublisher`, `toPublisher`.
This commit removes `GuavaCache` and support classes. Caffeine supersedes
the caching support in the Google Guava library with an actively maintained
Java 8+ version in standalone form.
As it is the only Guava feature Spring framework integrates with, this
commit removes effectively any reference to Guava.
Issue: SPR-13797
This commit adds support for handling an empty request body with both
HttpEntity where the body is not required and with @RequestBody where
the body is required depending on the annotation's required flag.
If the body is an explicit type (e.g. String, HttpEntity<String>) and
the body is required an exception is raised before the method is even
invoked or otherwise the body is passed in as null.
If the body is declared as an async type (e.g. Mono<String>,
HttpEntity<Mono<String>>) and is required, the error will flow through
the async type. If not required, the async type will be passed with no
values (i.e. empty).
A notable exception is rx.Single which can only have one value or one
error and cannot be empty. As a result currently the use of rx.Single
to represent the request body in any form effectively implies the body
is required.
Before this change decodeToMono always created a StringBuilder to
aggregate resulting in an "" (empty string) rather than an empty
Mono for an empty input stream.
Now we aggregate in the DataBuffer instead and then decode to String.
The RequestBodyArgumentResolver has been refactored to have a shared
base class and tests with the new HttpEntityMethodArgumentResolver.
An HttpEntity argument is not expected to have an async wrapper because
the request headers are available immediately. The body however can be
asynchronous, e.g. HttpEntity<Flux<String>>.
SPR-14055 introduced first-class support for the Java 8 Parameter API.
This commit therefore replaces the MethodParameterFactory with use of
the new SynthesizingMethodParameter.forParameter(Parameter) factory
method.
Issue: SPR-13575
This commit changes the AbstractResponseBodySubscriber into a
AbstractResponseBodyProcessor<DataBuffer, Void>, so that the processor
can be used as a return value for writeWith.
Additional, this commit no longer closes the response after an eror
occurred.
This fixes#59.
When the thread is writing to the response in
RECEIVED.onWritePossible(), the execution may stop because isReady()
returned false. In this case the buffer is partially written.
When there is partially written case:
1. The state will be changed from WRITING to RECEIVED
2. A check for "write possible" will be performed:
- If onWritePossible event has been already called by the web
container while in WRITING state then this check will trigger
RECEIVED.onWritePossible() because isReady() will be true and the
writing will continue.
- Otherwise the writing will be resumed when the web container sends
onWritePossible event.
This commit adds a test runtime dependency on log4j 2 for every project
and migrates all log4j.properties files to log4j2-test.xml files.
Issue: SPR-14431
This commit also removes the corresponding deprecated Servlet MVC variant and updates DispatcherServlet.properties to point to RequestMappingHandlerMapping/Adapter by default.
Issue: SPR-14129
This commit introduces initial support for JUnit Jupiter (i.e., the new
programming and extension models in JUnit 5) in the Spring TestContext
Framework.
Specifically, this commit introduces the following.
- SpringExtension: an implementation of multiple extension APIs from
JUnit Jupiter that provides full support for the existing feature set
of the Spring TestContext Framework. This support is enabled via
@ExtendWith(SpringExtension.class).
- @SpringJUnitConfig: a composed annotation that combines
@ExtendWith(SpringExtension.class) from JUnit Jupiter with
@ContextConfiguration from the Spring TestContext Framework.
- @SpringJUnitWebConfig: a composed annotation that combines
@ExtendWith(SpringExtension.class) from JUnit Jupiter with
@ContextConfiguration and @WebAppConfiguration from the Spring
TestContext Framework.
Issue: SPR-13575
Before this commit, it was not possible to set the status code of an
HTTP response without throwing an exception if it was already
committed. The consequence was a lot of errors in the logs for long
lived HTTP exchanges like Server-Sent Events for example.
After this commit, ServerHttpResponse#setStatusCode() returns
true if the operation succeeded and false if the status code has not
been set because the response has already been committed.
In term of implementation, that makes status code managed
consistently with headers and cookies:
AbstractServerHttpResponse#setStatusCode() stores the status
code that will be effectively set later in the response lifecycle by
the HTTP server via AbstractServerHttpResponse#writeStatusCode()
when the response will be committed.
When using the ConversionService to check and bridge to and from
reactive types we now generallly provide the full type information
available from method signatures. However that full type information
is not always necessary such as when we perform additional checks on
the generics of the reactive type (e.g. Mono<ResponseEntity>).
This allows us to switch to use DefaultFormattingConversionService
instead of GenericConversionService while also ensuring that the
CollectionToObjectConverter doesn't think it can convert List<?> to
any reactive type.
The ObjectToObjectConverter can also interfere because it is smart
enough to find the "from(Publisher<?>)" method on Flux and Mono.
To make up for that on the response side we now check if a type
is assignable to Publisher first in which case it is a simple cast.
In turn that means we don't need a PublisherToFluxConverter which can
be problematic in its own right because it can convert from Mono to
Flux which technically doesn't lose data but switches stream semantics.
Issue: #124, #128
HandlerAdapter's should always be able to provide a MethodParameter
which in turn ensures that HandlerResultHandler's have full type
information from method declarations.
This commit also introduces ResolvableMethod for use in tests to make
it easy to obtain MethodParameter return types.
Issue: #128
This commit adds a Decoder#decodeOne() method in order
to handle correctly the streaming versus one value
deserialization based on the type provided by the user.
For example, if a List parameter is provided in a controller
method, Jackson will be called once, while if the user provides
a Flux or an Observable parameter, Jackson will be called for
each element.
This commit replaces Reactive Streams converters for RxJava1 and
CompletableFuture with Reactor specific ones. The results in conversion
that preserves stream semantics, i.e. Mono vs Flux.
For example this is allowed:
Flux -> Observable
Mono -> Single
Mono -> CompletableFuture
This is not allowed:
Flux -> Single
Mono -> Observable
Flux -> CompletableFuture
As a result it is now possible to check through the ConversionService
if a target type to convert to is a stream of many or of one which is
useful for decoding purposes.
The commit also adds PublisherToFluxConverter to allow conversion from
raw Publisher to Flux. The reverse is not necessary since Flux is a
Publisher and it's a no-op conversion.
The DefaultWebSessionManager now uses Mono.defer to protect the call
to getSession from parsing session cookies immediately. This allows
pre-initializing the Mono<WebSession> upfront vs using a lock.
When in state DATA_AVAILABLE if there are simultaneous invocations of
AbstractRequestBodyPublisher.RequestBodySubscription.request and
ReadListener.onDataAvailable, the first one will process the available
data, the second one should not throw an exception because thus it will
signal to web container that there are problems while there are not.
Refactored Undertow support to register a response listener only when
the body is written to, as opposed to registering it at startup. The
reason for this is that getting the response channel from the
HttpServerExchange commits the status and response, making it impossible
to change them after the fact.
Fixed issue #119.
When there are simultaneous invocations of onWritePossible, only the
first one should succeed. This can happens when
AbstractResponseBodySubscriber.onNext and
WriteListener.onWritePossible() are called respectively by the
application and the web container.
Originally handleNoMatch looked for partial matches based on URL
pattern, HTTP method, consumes, produces, and params in that order
but without narrowing down the set of partial matches resulting in
potentially inaccruate response status codes
Commit 473de0 added an improvement to narrow the set with partial
matches for URL pattern and HTTP method matches.
This commit overhauls handleNoMatch so that the narrowing down of
matches happens at each stage resulting in more accurate error
reporting for request mappings with fine-grained conditions.
Issue: SPR-14397
This commit fixes MessagingMessageConverter to no longer expose the lazy
message resolution algorithm. This restores proper behaviour for
converters used outside of that context.
Instead, such arrangement is now private to
AbstractAdaptableMessageListener (as it should).
Issue: SPR-14389
The `CacheResolver` and `ErrorHandler` features introduced in 4.1 were
not properly enabled in AspectJ mode. This commit adds more tests from
the regular proxy-based mode and align the AspectJ caching configuration.
Issue: SPR-14413
This commit adds a `ClientHttpRequestInterceptor` that applies a BASIC
authorization header for each request.
It can be used as follows:
```
BasicAuthorizationInterceptor basicAuthorization =
new BasicAuthorizationInterceptor("user", "secret");
restTemplate.getInterceptors().add(basicAuthorization);
```
Issue: SPR-14412
Reactored Servlet 3.1 and Undertow request support
(AbstractResponseBodySubscriber) to use an internal state machine,
making thread-safity a lot easier.
As of 4.3 ResourceHttpRequestHandler delegates to the configured
ContentNegotiationManager, or one created internally, to look up
the media type for are resource.
This commit ensures the internally created ContentNegotiationManager is
correctly injected with the ServletContext through which it can perform
lookups as before.
Also the ServletPathContentNegotiationStrategy now checks the
ServletContext first and then delegates to its parent the
PathContentNegotiationStrategy and not vice versa. This is
consistent with how handleNoMatch (also in the same class) works
and also matches how ResourceHttpRequestHandler worked before 4.3.
Issue: SPR-14368
This commit sets the response content type to
"text/event-stream;charset=UTF-8". Even if the SSE spec says that the
encoding should always be UTF-8 and that specifying the charset is
optional, we're setting it in all cases, since some containers might use
the default encoding "ISO-8859-1" and confuse HTTP clients.
Issue: SPR-14407
Currently ResponseEntityResultHandler is ordered lower than
ResponseBodyResultHandler by default whch means a ResponseEntity
should not be picked by the ResponseBodyResultHandler.
However as it is easy to have both ResponseEntity and @ResponseBody
e.g. in @RestControler (or even by mistake) and in general it makes
sense for ResponseBodyResultHandler to explicitly recognize and
ignore the ResponseEntity return type.
Before this commit only ResponseEntity with async body was supported,
e.g. ResponseEntity<Mono<String>>
This commit also adds suppport for an asyn wrapper around,
e.g. Mono<ResponseEntity<String>.
Introduce separate test classes for each base class in the hierarchy
above @ResponseBody and ResponseEntity result handlers.
Also start porting existing unit test cases for @ResponseBody and
ResponseEntity return value handlers.
Reactored Servlet 3.1 and Undertow response support into an
AbstractResponseBodySubscriber that uses an internal state machine,
making thread-safity a lot easier.
Flux<SseEvent> is Spring Web Reactive equivalent to Spring MVC
SseEmitter type. It allows to send Server-Sent Events in a reactive way.
Sending Flux<String> or Flux<Pojo> is equivalent to sending
Flux<SseEvent> with the data property set to the String or
Pojo value. For example:
@RestController
public class SseController {
@RequestMapping("/sse/string")
Flux<String> string() {
return Flux.interval(Duration.ofSeconds(1)).map(l -> "foo " + l);
}
@RequestMapping("/sse/person")
Flux<Person> person() {
return Flux.interval(Duration.ofSeconds(1)).map(l -> new Person(Long.toString(l), "foo", "bar"));
}
@RequestMapping("/sse-raw")
Flux<SseEvent> sse() {
return Flux.interval(Duration.ofSeconds(1)).map(l -> {
SseEvent event = new SseEvent();
event.setId(Long.toString(l));
event.setData("foo\nbar");
event.setComment("bar\nbaz");
return event;
});
}
}
This commit updates AbstractHandlerExceptionResolver to only log at the
WARN level exceptions that are actually resolved by the
ExceptionResolver.
In case developers wish to log each time an ExceptionResolver is called,
a DEBUG level log is still available.
Issue: SPR-14392
Prior to this commit, any attempt to include a bean of type
ServletServerContainerFactoryBean in the WebApplicationContext for an
integration test class annotated with @WebAppConfiguration in
conjunction the Spring TestContext Framework (TCF) would have resulted
in an IllegalStateException stating that "A ServletContext is required
to access the javax.websocket.server.ServerContainer instance."
In such scenarios, the MockServletContext was in fact present in the
WebApplicationContext; however there was no WebSocket ServerContainer
stored in the ServletContext.
This commit addresses this issue by introducing the following.
- MockServerContainer: a private mock implementation of the
javax.websocket.server.ServerContainer interface.
- MockServerContainerContextCustomizer: a ContextCustomizer that
instantiates a new MockServerContainer and stores it in the
ServletContext under the attribute named
"javax.websocket.server.ServerContainer".
- MockServerContainerContextCustomizerFactory: a
ContextCustomizerFactory which creates a
MockServerContainerContextCustomizer if WebSocket support is present
in the classpath and the test class is annotated with
@WebAppConfiguration. This factory is registered by default via the
spring.factories mechanism.
Issue: SPR-14367
When comparing multiple matching @RequestMapping's, the HTTP method
condition has the lowest precedence. It's mainly about ensuring an
explicit mapping wins over an implicit (i.e. no method) one.
As of 4.3 HTTP HEAD is handled automatically for controller methods
that match to GET. However an explicit mapping HTTP HEAD allows an
application to take control.
This commit ensures that for HTTP HEAD requests the HTTP method
condition is checked first which means that an explicit HEAD mapping
now trumps all other conditions.
Normally we look for the most specific matching @RequestMapping.
For HTTP HEAD we now look for the most specific match among
@RequestMapping methods with a HEAD mapping first.
Issue: SPR-14383
This commit also fixes an issue in the HTTP client that used the
wrapper type instead of the element type. As a consequence, due
to type erasure, we now have to specify the type of the content
in DefaultHttpRequestBuilder#contentStream().
Even before this change SockJS sessions always cancelled the heartbeat
task first prior to sending messages. However when the heartbeat task
is already in progress, cancellation of it is not enough and we must
wait until the heartbeat is sent.
This commit adds a heartbeat write lock which is obtained and held
during the sending of a heartbeat. Now when sessions send a message
they still cancel the heartbeat task but if that fails they also wait
for the heartbeat write lock.
Issue: SPR-14356
ReflectionTestUtils invokes toString() on target objects in order to
build exception and logging messages, and prior to this commit problems
could occur if the invocation of toString() threw an exception.
This commit addresses this issue by ensuring that all invocations of
toString() on target objects within ReflectionTestUtils are performed
safely within try-catch blocks.
Issue: SPR-14363
In the process of upgrading the build to use Gradle 2.14, the
setFieldOnLegacyEntityWithSideEffectsInToString() test method in
ReflectionTestUtilsTests began to fail. The reason is that the log
level for ReflectionTestUtils is now DEBUG by default with Gradle 2.14.
The apparent cause is that log4j was present on the test runtime
classpath for the spring-test module with all previous versions of
Gradle (via a transitive optional dependency from another project that
spring-test depends on). Thus the configuration in log4j.properties in
spring-test was previously honored, but with Gradle 2.14 a different
commons logging implementation is picked up.
Thus, in addition to upgrading the build to Gradle 2.14, this commit
introduces an explicit test runtime dependency on log4j in the
spring-test module.
The discovered bug in ReflectionTestUtils regarding DEBUG log level
will be addressed separately.
Issue: SPR-14362
Renamed getSupportedMimeTypes() to getEncodableMimeTypes and
getDecodableMimeTypes. This will allow for both Encoder and Decoder to
be implemented in the same class.
This issue fixes#113.
The Pojo test class from the codec package will end up in spring-core.
This commit ensures it is used only from classes that also belong to
spring-core.
After the fix for ReactiveX/RxNetty#509 we can remove the workaround
to concatenate with an empty Observable for the request body and
upgrade to the latest RxJava 1.1.5.
Issues: #103
ViewResolutionResultHandler and ResponseBodyResultHandler now share
a common base class ContentNegotiatingResultHandlerSupport that
supports content negotiation.
For view resolution we compare against the supported media types of
resolved View instances, which may include default View's delegating
to an HttpMessageConverter (e.g. JSON, XML, rendering).
View now returns Mono<Void> rather than Flux<DataBuffer> which aligns
more closely with the reactive HttpMessageConverter vs the Encoder.
The change was prompted by the upcoming implementation of a View that
delegates to an existing HttpMessageConverter e.g. for JSON, XML.
The resulting change also brings the reactive View closer in spirit to
the View from spring-webmvc which returns void.
The ContentNegotiatingResultHandlerSupport base class encapsulates the
logic for content negotiation needed for both @ResponseBody and view
resolution result handling.
Before this change Consumes/ProducesRequestCondition shared a common
match method in the package private AbstractMediaTypeExpression. The
benefit, two lines of code, was negligible but was forcing each
condition into parsing the content type of the request body or
evaluating the content type for the response respectively.
This change removes the shared match method and brings it down into
each sub-class resulting in a performance improvement as well as in
simpler code including exception handling.
Issue: SPR-14299
Previously MockMvcWebConnection did not update the cookie manager with the
cookies from MockHttpServletResponse. This meant that newly added cookies
are not saved to the cookie manager and thus are not presented in the next
request.
This commit ensures that MockMvcWebConnection stores the response cookies
in the cookie manager.
Issue: SPR-14265
This commit adds support for Model-related return values types such as
Map, Model, @ModelAttribute annotated, and non-simple types, which
helps to clarify the logic in ViewResolutionResultHandler.
In order to be more "reactive", changed StringDecoder's default from
merging all buffers in the stream to a single buffer into splitting the
buffers along newline (\r, \n) characters.
This commit introduces DataBuffer.indexOf(IntPredicate) and
lastIndexOf(IntPredicate), for finding the index of a byte in a
DataBuffer.
It also introduces DataBufferUtils.tokenize, which tokenizes a
DataBuffer into separate tokens, given a delimiter function.
While View and ViewResolver play the same role as in spring-webmvc they
are now abstracted behind the HandlerResultHandler abstraction so that
top-level contracts don't reference them and the DispatcherHandler is
also unaware of their existence.
Furthermore view resolution and response body handling which are now at
the same level of abstraction (each is a HandlerResultHandler) will
also share code for content negotiation, so it makes sense for them to
be side by side.
This commit moves the reactive.view package to reactive.result.view
with the View and ViewResolver contracts (previously in the top-level
reactive package) also moving there.
When a null is returned from an @ResponseBody method, rather than
returning Mono.empty() immediately, convert it to Mono.empty() and
apply the same processing.
Currently that doesn't make a practical difference but it's more
accurate to do it this way. Eventually it may mean the possibility
to turn empty values into something through an extension point
as we do with ResponseBodyAdvice in Spring MVC today.
Normally heartbeats keep connections from hanging. However in some
cases a connection may hang before a CONNECTED frame is received
and heartbeats are put in place. This commit adds a change to enforce
a 60 limit on receiving the CONNECTED frame.
Issue: SPR-14266
Since the user controls the value of `spring.status.value`, you wouldn't want to echo unescaped values here in this form. Otherwise one could submit a value of, say, `"/> <script>alert("pwned")</script>`.
Prior to Java 8 it never really made much sense to author integration
tests using interfaces. Consequently, the Spring TestContext Framework
has never supported finding test-related annotations on interfaces in
its search algorithms.
However, Java 8's support for interface default methods introduces new
testing use cases for which it makes sense to declare test
configuration (e.g., @ContextConfiguration, etc.) on an interface
containing default methods instead of on an abstract base class.
This commit ensures that all non-repeatable, class-level test
annotations in the Spring TestContext Framework can now be declared on
test interfaces. The only test annotations that cannot be declared on
interfaces are therefore @Sql and @SqlGroup.
Issue: SPR-14184
Prior to this commit the SpEL compiler would generate bad bytecode
if the left hand operand of an instanceof was a primitive or
if the right hand operand was a primitive type reference.
With the fixes primitives on the left hand side are now
correctly boxed and special handling is in place for when the
right hand side is a primitive type reference. Using a primitive
type reference on the right always causes the instanceof
check to return false.
Additionally a guard has been added such that compilation is
not allowed when the right hand side of an expression
is not a type reference. If it is, for example, a variable
reference that evaluates to a type reference then that
cannot be expressed in bytecode so compilation is not performed.
Issue: SPR-14250
Prior to this commit, the latest optimizations introduced in SPR-13913
would prevent matching when patterns contained spaces. Indeed, the
optimized path would not fully tokenize the paths nor trim the tokens,
as the "longer" code path does.
This commit disables this optimized path when the `trimTokens` option is
set to `true`.
Also, the `trimTokens` setting is now set to `false` by default.
Issue: SPR-14247
Prior to this commit, information regarding avoiding false positives
when testing with JPA had already been added to the Testing chapter of
the reference manual. However, the example did not work properly and
the accompanying text mixed concepts from Hibernate and JPA.
This commit fixes the @Autowired/@PersistenceContext bug, updates the
text, and marks each test as @Transactional in order to avoid any
misinterpretation.
Issue: SPR-9032
Prior to this commit, @BeforeTransaction and @AfterTransaction could
only be declared on methods within test classes. However, JUnit 5 as
well as some existing third-party Runner implementations for JUnit 4
already support Java 8 based interface default methods in various
scenarios -- for example, @Test, @BeforeEach, etc.
This commit brings the Spring TestContext Framework up to date by
supporting the declaration of @BeforeTransaction and @AfterTransaction
on interface default methods.
Issue: SPR-14183
This commit updates the Testing chapter in the reference manual to
refer explicitly to JUnit 4 instead of just "JUnit" (where appropriate)
in order to avoid confusion with forthcoming support for JUnit 5.
SendTo and SendToUser are treated as mutually exclusive. The addition of
type-level support in 4.3. RC1 however did not consider the possibility
to mix and match of the two betwee type and method level.
This commit consolidates the detection of SendTo and SendToUser
annotations and considers them all together.
Issue: SPR-14238
Prior to this commit, setting the `forceEncoding` option would force
encoding on both requests and responses.
This commit adds two new setters and a new constructor to differentiate
both options: forcing the encoding on the request and/or on the
response.
You can now define this filter programmatically using those options or
update your servlet XML configuration like:
```
<filter>
<filter-name>characterEncodingFilter</filter-name>
<filter-class>o.sf.web.filter.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<init-param>
<param-name>forceRequestEncoding</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>forceResponseEncoding</param-name>
<param-value>false</param-value>
</init-param>
</filter>
```
Issue: SPR-14240
Prior to this commit, the `ResourceHttpMessageConverter` would support
all HTTP Range requests and `MethodProcessors` would "wrap" controller
handler return values with a `HttpRangeResource` to support that use
case in Controllers.
This commit refactors that support in several ways:
* a new ResourceRegion class has been introduced
* a new, separate, ResourceRegionHttpMessageConverter handles the HTTP
range use cases when serving static resources with the
ResourceHttpRequestHandler
* the support of HTTP range requests on Controller handlers has been
removed until a better solution is found
Issue: SPR-14221, SPR-13834
This commit makes sure that HTTP request headers containing ETag values
are properly parsed and not simply tokenized using a "," separator.
Indeed, ETags can legally contain separator characters such as " " and
",".
Issue: SPR-14216
Prior to this change, getting header values with `HttpHeaders` when
headers are multi-valued would cause issues.
For example, for a given HTTP message with headers:
Cache-Control: public, s-maxage=50
Cache-Control: max-age=42
Getting a `List` of all values would return <"public", "s-maxage=50">
and getting the header value would return "public, s-maxage=50".
This commit takes now into account multi-valued HTTP headers and adds
new getters/setters for "If-Match" and "If-Unmodified-Since" headers.
Note that for ETag-related headers such as "If-Match" and
"If-None-Match", a special parser has been implemented since ETag values
can contain separator characters.
Issue: SPR-14223, SPR-14228
Resources are now retrieved using the application context in order to
support natively non-classpath locations like /WEB-INF/...
As a consequence of this refactoring, ScriptTemplateView#createClassLoader()
protected method as been removed, since it did not make sense anymore with
this new resource loading implementation.
Issue: SPR-14210
Prior to this change, setting both "If-None-Match" and
"If-Unmodified-Since" conditional request headers would check for both
conditions to be met.
This commit fixes this behavior to follow the RFC7232 Section 6:
> entity tags are presumed to be more accurate than date validators
So in case both conditions are present, the "If-None-Match" condition
takes precedence.
Issue: SPR-14224
This commit introduces a pooled data buffer as a subtype of DataBuffer,
as well as various utility methods related to reference counting.
Additionally, Crelease calls have been introduced throughout the
codebase to properly dispose of pooled databuffers.
Previously MockWebResponseBuilder would use the cookie domain of the cookie
received from MockMvc response. This caused problems because the cookie
domain can be null, but HtmlUnit forbids a null domain.
This commit defaults the domain of the cookie to the domain of the
WebRequest.
Issues SPR-14169
It's handy to know in advance whether or not expression that is
passed to CronSequenceGenerator or CronTrigger constructor would
not results in IllegalArgumentException. The only way to do it
now is to try\catch an instance creation but it's kinda ugly.
Rename two classes each adapting to WebHandler to avoid confusing them:
1. HttpWebHandlerAdapter adapts from the low level HttpHandler to any
WebHandler (e.g. DispatcherHandler).
2. SimpleHandlerAdapter adapts the plain WebHandler for use within the
DispatcherHandler.
This commit also fixes an issue in WebHttpHandlerBuilder to ensure that
WebExceptionHandler's are inserted before and not after WebFilter's.
The renaming makes it clear this exception is for use where 400 error
applies within a Spring web application where the error may be
associated with a MethodParameter, a BindingResult, and so on.
There is no need for BadRequestStatusException which can be expressed
with ResponseStatusException(HttpStatus.BAD_REQUEST, "reason").
This commit wraps up the previous commits:
- It uses HttpMessageConverter in the web.reactive.server package instead of Encoder/Decoder.
- It introduces tests for the Resource @ResponseBodies.
This commit introduces a reactive version of the HttpMessageConverter.
During the implementation of zero-copy support, it became apparent that
it was ueful to have a common abstraction between client and server that
operated on HttpMessages rather than DataBuffers.
Two HttpMessageConverter implementations are provided:
- The CodecHttpMessageConverter, based on Encoder/Decoder.
- The ResourceHttpMessageConverter, using zero-copy if available.
This commit introduces support for zero-copy file transfers in the HTTP
response, through the ZeroCopyHttpOutputMessage subinterface of
ReactiveHttpOutputMessage.
This commit introduces two DataBuffer improvements:
- The capability to read a Flux<DataBuffer> from an input stream or
channel.
- The capability to limit a Publisher<DataBuffer> to publish up until a
given maximum byte count.
Now that we have a CompositeContentTypeResolverBuilder with built-in
defaults, we switch to those defaults in places where a
ContentTypeResolver is used.
Rename to MappingContentTypeResolver and replace "fileExtension" with
"key" in methods to be more general (e.g. file extension or query
param). Also switch from List to Set for the return values.
This commit introduces @Ignore'd tests for future support for declaring
@BeforeTransaction and @AfterTransaction on interface default methods.
Issue: SPR-14183
Prior to this commit, the new match algorithm wouldn't work for multiple
consecutive path separators.
This commit separately matches path segments and path separators and
allows for multiple, consecutive path separators.
Issue: SPR-14141
A pretty complete equivalent to the same in spring-webmvc except for
CORS checks, and custom HTTP methods. Another notable difference is
that the "params" condition works on query params strictly.
Previously using the Gradle Daemon with import eclipse scripts would cause
issues with the merge plugin. Specifically, projects would randomly not
be associated to the classpath.
This change explicitly adds --no-daemon in the import scripts to ensure
that the problem does not occur.
Issue SPR-14102
Spring uses lots of forbidden references. The current Eclipse settings
set forbiddenReference=error This was not ideal because there were lots of
errors in the workspace.
This commit changes forbiddenReference=warning since we nee to allow
forbidden references.
Previously HtmlUnitRequestBuilder did not decode parameter names. This
means if a parameter like row[0] was submittted it would be encoded as
row%5B0%5D When the HttpServletRequest was created the parameter name would
not be decoded so the parameter name row[0] would not be found.
This commit ensures that HTTP parameter names are decoded.
Issue SPR-14177
This commit makes sure to reject an `@EventListener` annotated method
that also uses `@Async`. In such scenario, the method is invoked in a
separate thread and the infrastructure has no handle on the actual reply,
if any.
The documentation has been improved to refer to that scenario.
Issue: SPR-14113
This commit adds AbstractHandlerMethodMapping, a starting point for
AbstractHandlerMapping, and HttpRequestPathHelper with a similar
purpose to UrlPathHelper but based with ServerWebExchange as input.
- correct name of HttpHandlerHandlerAdapter to WebHandlerHandlerAdapter
- shorten SimpleHandlerResultHandler to SimpleResultHandler
- add HandlerResult constructor without Model
- update tests
This commit adds the "*/*" media type in the list of compatible media
types for the StringDecoder. This allows this decoder to decoder
payloads of any media type as long as the target type is String.
Fixes#87
This commit introduces a new method in TestPropertySourceUtils that
allows properties files to be added directly to the environment without
the need for a ConfigurableApplicationContext upfront; however, a
ResourceLoader is still necessary.
Issue: SPR-14131
This commit underlines the fact that the request created by a
ClientHttpRequestFactory should be augmented with a message body using
the `ClientHttpRequest#setBody` method before it is executed.
See #82
This commit makes messageEncoders a required argument for building a
client request - those are needed to actually encode the body object as
a reactive stream to be written to the HTTP request body.
Removed raw types usage in DefaultHttpRequestBuilder.
DefaultHttpRequestBuilder now uses a UriTemplateHandler to expand URI
templates + variables into a concrete URI.
Fixes#80, fixes#85, fixes#86
This commit introduces the new `WebClientException` for wrapping
client-side exceptions.
This exception is now thrown when now message encoder can be found for
writing the request body as an HTTP request message.
Fixes#83
This commit adds generics support for WebResponseExtractors.
Types should be described using a ResolvableType, which can be
created with static methods like:
// for the type Event<Registration>
ResolvableType.forClassWithGenerics(Event.class, Registration.class)
Fixes#89
- Introcuces XmlEventDecoder which decodes from DataBuffer to
javax.xml.stream.events.XMLEvent. It uses the Aalto async XML API if
available, but falls back to a blocking default if not.
- Refacors Jaxb2Decoder to use said XmlEventDecoder, and split the
stream of events into separate substreams by using the JAXB annotation
value, one stream for each part of the tree that can be unmarshaled to
the given type.
- Various improvements in the JAXB code.
Previous refactoring (fcf6ae and also 43d937) in the SockJsSession
hierarchy consolidated access to the request and response in the
base class AbstractHttpSockJsSession in order to keep synchronization
concerns there. However that also unintentionally removed the call to
resetRequest() after sending a heartbeat for any of the
PollingSockJsSession classes. In general a polling session should call
resetRequest after every frame written.
This commit brings back the writeFrame override in PollingSockJsSession
with an extra call to resetRequest().
Issue: SPR-14107
Prior to this commit, the size of the ApplicationContext cache in the
Spring TestContext Framework could grow without bound, leading to
issues with memory and performance in large test suites.
This commit addresses this issue by introducing support for setting the
maximum cache size via a JVM system property or Spring property called
"spring.test.context.cache.maxSize". If no such property is set, a
default value of 32 will be used.
Furthermore, the DefaultContextCache has been refactored to use a
synchronized LRU cache internally instead of a ConcurrentHashMap. The
LRU cache is a simple bounded cache with a "least recently used" (LRU)
eviction policy.
Issue: SPR-8055
Commit 48236b from 2014 introduced a logging improvement to avoid
logging each removed session per line and instead log one line at
the end with all removed sessions ids. However that list of removed
session ids wasn't populated. This commit fixes that.
Issue: SPR-14111
This commit documents the @Ignore'd test to explain that Spring does not
support a hybrid approach for annotation attribute overrides with
transitive implicit aliases.
Issue: SPR-13554
OkHttp3 introduces a new package and API that is incompatible with
previous versions. This commit adds a new
OkHttp3ClientHttpRequestFactory and supporting classes.
This commit reverts the recently added merged annotation support for
Spring's JMX annotations by once again using the simpler searches for
repeatable annotations in AnnotationUtils.
Issue: SPR-13973
Prior to this commit, the `HttpInvokerServiceExporter` would close
its `ObjectOutputStream`, which itself issues duplicate flushes on the
underlying `OutputStream`. Duplicate flushes can lead to multiple,
separate TCP packets where those should be gathered writes.
This commit wraps the underying stream with a decorator that guards
against flush calls that are duplicated with the one done in `close`.
Issue: SPR-14040
Prior to this commit, HTTP clients relying on the JDK HTTP client would
not properly reuse existing TCP connections (i.e. HTTP 1.1 persisten
connection). The SimpleClientHttpResponse would close the actual connection once the
response is handled.
As explained in the JDK documentation
(http://docs.oracle.com/javase/8/docs/technotes/guides/net/http-keepalive.html)
HTTP clients should do the following to allow resource reuse:
* consume the whole HTTP response content
* close the response inputstream once done
This commit makes sure that the response content is
totally drained and then the stream closed (and not the connection).
Issue: SPR-14040
Prior to this commit, binding a `@ModelAttribute` object as a Controller
handler paramater would instantiate the object and set all its
properties, fetching data from the request. When no data is available,
the WebDataBinder tries to bind default "empty" values:
* Boolean.FALSE for boolean types
* empty arrays for array types
* null by default
This commit adds the new default empty values:
* empty Collections for Collection types
* empty Maps for Map types
Rather than using empty implementations provided by `Collections.empty`
(which are not mutable), we're using the closest possible target type
and real implementations, provided by the `CollectionFactory`.
Issue: SPR-13502
This commit introduces a boolean alwaysProcesses() method in the
Processor API which allows for simplification across all search
algorithms within AnnotatedElementUtils.
Specifically, it is no longer necessary for process() methods to verify
that the supplied annotation is actually the sought target annotation.
In addition, duplicated code has been extracted into common methods
(e.g., hasMetaAnnotationTypes()) and common Processor implementations
(e.g., AlwaysTrueBooleanAnnotationProcessor).
This commit picks up where 2535469099 left off with added support for
"get" search semantics for merged repeatable annotations.
Specifically, this commit introduces a new
getMergedRepeatableAnnotations() method in AnnotatedElementUtils.
Issue: SPR-13973
This commit picks up where a5139f3c66 left off with added support for
"get" search semantics for multiple merged annotations.
Specifically, this commit introduces a new getAllMergedAnnotations()
method in AnnotatedElementUtils.
Issue: SPR-13486
Prior to this commit, AnnotationUtils supported searching for
repeatable annotations even if the repeatable annotation was declared
on a custom stereotype annotation. However, there was no support for
merging of attributes in composed repeatable annotations. In other
words, it was not possible for a custom annotation to override
attributes in a repeatable annotation.
This commit addresses this by introducing
findMergedRepeatableAnnotations() methods in AnnotatedElementUtils.
These new methods provide full support for explicit annotation
attribute overrides configured via @AliasFor (as well as
convention-based overrides) with "find semantics".
Issue: SPR-13973
This commit resolves a few comments brought forward during a review
meeting, specifically:
- It renames AbstractResponseBodyPublisher to
AbstractRequestBodyPublisher.
- It separates out registration logic into a register method.
- It moves the RequestBodyPublisher and ResponseBodySubscriber for the
Servlet 3.1 support back into ServletHttpHandlerAdapter.
Prior to this commit, HTTP Range requests were only supported by the
ResourceHttpRequestHandler when serving static resources.
This commit improves the ResourceHttpMessageConverter that
now supports partial writes of Resources.
For this, the `HttpEntityMethodProcessor` and
`RequestResponseBodyMethodProcessor` now wrap resources with HTTP
range information in a `HttpRangeResource`, if necessary. The
message converter handle those types and knows how to handle partial
writes.
Controller methods can now handle Range requests for
return types that extend Resource or HttpEntity:
@RequestMapping("/example/video.mp4")
public Resource handler() { }
@RequestMapping("/example/video.mp4")
public HttpEntity<Resource> handler() { }
Issue: SPR-13834
Just like SPR-13252 addressed this issue for the "Pragma" header, this
issue resets the HTTP 1.0 "Expires" header.
When such a header has been set (by a filter, for example) and HTTP
caching has been configured at the WebContentGenerator, this header
value is reset to "". In this case, "Cache-Control" and "Expires" might
have inconsistent values and we consider that the HTTP caching
configuration should take precedence.
Depending on the servlet container chosen to deploy the application,
this might result in empty "" header values or no header set at all.
Issue: SPR-14053
Prior to this commit, @Cacheable, @CacheEvict, @CachePut, and @Caching
could be used to create custom stereotype annotations with hardcoded
values for their attributes; however, it was not possible to create
composed annotations with attribute overrides.
This commit addresses this issue by refactoring
SpringCacheAnnotationParser to use the newly introduced
findAllMergedAnnotations() method in AnnotatedElementUtils. As a
result, @Cacheable, @CacheEvict, @CachePut, and @Caching can now be
used to create custom composed annotations with attribute overrides
configured via @AliasFor.
Issue: SPR-13475
Prior to this commit it was possible to search for the 1st merged
annotation above an annotated element. It was also possible to search
for annotation attributes aggregated from all annotations above an
annotated element; however, it was impossible to search for all
composed annotations above an annotated element and have the results as
synthesized merged annotations instead of a multi-map of attributes.
This commit introduces a new findAllMergedAnnotations() method in
AnnotatedElementUtils that finds all annotations of the specified type
within the annotation hierarchy above the supplied element. For each
such annotation found, it merges that annotation's attributes with
matching attributes from annotations in lower levels of the annotation
hierarchy and synthesizes the results back into an annotation of the
specified type. All such merged annotations are collected and returned
as a set.
Issue: SPR-13486
This commit introduces tests that verify the status quo for finding
multiple merged composed annotations on a single annotated element.
Issue: SPR-13486
Prior to this commit, it was possible that implicit aliases and
transitive implicit aliases (configured via @AliasFor) might not be
honored in certain circumstances, in particular if implicit aliases
were declared to override different attributes within an alias pair in
the target meta-annotation.
This commit addresses this issue by ensuring that all aliased
attributes in the target meta-annotation are overridden during the
merge process in AnnotatedElementUtils.
In addition, concrete default values for attributes in a
meta-annotation declaration can now be effectively shadowed by
transitive implicit aliases in composed annotations.
Issue: SPR-14069
JSON payloads are sometimes prepended with a static string prefix
to prevent Cross Site Scripting Inclusion attacks (XSSI).
Prior to this commit, doing so would fail the MockMvc
`JsonPathResultMatchers` since they're considering the whole response as
the JSON payload.
This commit adds a new `JsonPathResultMatchers.prefix` method that
configures the matchers to check for the presence of that string (i.e.
fail if it's not there) and only consider the rest of the response body
as the JSON payload for other assertions.
Issue: SPR-13577
Previously MockMvc builders failed to share the WebConnection used for
managing cookies in the MockMvcWebConnection. This meant that the various
CookieManagers would have different states.
This commit ensures that the WebConnection is set on the
MockMvcWebConnection.
Fixes SPR-14066
This commit introduces a test to demonstrate that inlined properties
override properties loaded from Properties files in
@TestPropertySource.
Issue: SPR-14068
Currently there are clashes between io.netty:netty-common:4.1.0.Beta7 and
io.netty:netty-all:4.1.0.CR3 which can cause errors in the build related
to "VerifyError: Bad type on operand stack".
One solution would be to exclude the jars that duplicate the classes.
However, this can be fragile since additional dependencies may be added
that bring in the dependency transitively.
This commit locks the version for any artifiact with the group "io.nettty"
to ensure the correct version of netty is used.
* SPR-14050:
Fully test proxy support in ReflectionTestUtils
Polishing
Document proxy support in ReflectionTestUtils
Fix bugs in ReflectionTestUtils related to proxies
Polishing
Support proxied objects in ReflectionTestUtils
This commit adds support for unwrapping proxies in the setField() and
getField() methods in ReflectionTestUtils.
Instead of always accessing fields directly on the supplied
targetObject (which may be a proxy), AopTestUtils is now used to obtain
the potential ultimateTargetObject which is then used for accessing
fields.
Issue: SPR-14050
Before this commit the DefaultUserDestinationResolver did not support
well broker destinations that use dot as separator with a built in
assumptions that the destinations it resolves must start with slash.
This change adds PathMatcher property that is used to determine if
an alternative path separator is in use and if so the leading slash is
left out.
Issue: SPR-14044
This commit primarily allows for a `SynthesizingMethodParameter` to be
created for a `Constructor` parameter but also introduces an additional
overloaded constructor from `MethodParameter`.
Issue: SPR-14054
Previously, a package private `@ManagedResource` annotated bean was
registered to the JMX domain even if any attempt to invoke an operation
on it will fail since it has to be public.
This commit validates that any `@ManagedResource` annotated bean is
public and throws an InvalidMetadataException otherwise. Note that the
actual bean type does not have to be public as long as the class
annotated with `@ManagedResource` in the hierarchy is pubic and no extra
operations or attributes are defined on the child.
Issue: SPR-14042
The DeferredResult~ and the ResponseBodyEmitterReturnValueHandler now
each expose an adapter mechanism for plugging in other async return
value types. As a result the ListenableFutureReturnValueHandler and
CompletionStageReturnValueHandler are no longer needed and are now
deprecated.
Issue: SPR-14046
Allow third-parties to contribute ContextCustomizers that can customize
ApplicationContexts created by the Spring TestContext Framework (TCF)
before they are refreshed.
A customizer may be provided via a ContextCustomizerFactory which is
registered with `spring.factories`. Each factory is consulted whenever
a new ApplicationContext needs to be created by the TCF. Factories may
inspect various details about the test and either return a new
ContextCustomizer or null.
ContextCustomizers are similar to ApplicationContextInitializers and
may perform any number of tasks, including bean registration, setting
of active profiles, etc.
Issue: SPR-13998
The MultiServerUserRegistry now supports scenarios where the same user
is connected to multiple servers. For such cases the SimpUser returned
from the registry exposes all sessions across all servers.
Issue: SPR-13800
Add a ServletTestExecutionListener.ACTIVATE_LISTENER attribute which
can be set on the TestContext to trigger activation of the listener
even if a `@WebAppConfiguration` is not present.
Issue: SPR-14035
This commit adds a new "validator" XML attribute to the
`<websocket:message-broker/>` element. This allows configuring a
specific Validator to be used for payload validation.
Issue: SPR-13996
Previously, the generic type of a simple pojo event implementing
ResolvableTypeProvider wasn't detected properly. This commit fixes the
logic when the generic type is not provided to reuse what
PayloadApplicationEvent is already doing anyway.
Issue: SPR-14029
Prior to this commit, the @ContextConfiguration annotation was required
to be present even if default XML files, Groovy scripts, or
@Configuration classes were detected; however, in such cases the
@ContextConfiguration was typically declared empty and therefore
seemingly unnecessary boilerplate.
This commit permits @ContextConfiguration to be omitted whenever it can
be reasonably deduced. Consequently, integration tests such as the
following are now supported.
@RunWith(SpringRunner.class)
public class MyTest {
@Autowired String myBean;
@Test public void example() { /* ... */ }
@Configuration
static class Config {
@Bean String myBean() {
return "Hello";
}
}
}
Issue: SPR-13955
Prior to this commit, the springUrl Velocity macro would only prepend
the context to the given URL; this means that the
ServletHttpResponse.encodeUri method is not called and neither the
ResourceUrlProvider.
This commit changes this macro to use RequestContext.getContextUrl which
prepends the context and encodes the URI.
Issue: SPR-14027
Update @WebAppConfiguration so that it no longer directly specifies
a TestContextBootstrapper. This allows third parties to use the
annotation in combination with their own bootstrapper.
BootstrapUtils now provides the detection logic for when
WebTestContextBootstrapper should be used.
Issue: SPR-13991
WebResponseExtractor uses Mono.when with the response status, headers,
and the decoded body. However when the response body stream is empty
then when completes empty too.
This change adds defaultIfEmpty handling for en empty response body.
This commit picks up where 8ff9e818a5
left off.
Specifically, this commit introduces support that allows a single
element attribute to override an array attribute with a matching
component type when synthesizing annotations (e.g., in annotations
synthesized from attributes that have been merged from the annotation
hierarchy above a composed annotation).
Issue: SPR-13972
The ResourceHttpRequestHandler now relies on the conifgured
ContentNegotiationManager to determine the content type for resource
requests rather than implementing that internally.
First we check against the matched resource based on the resource file
extension. Then we expand the check against the request with any
configured content negotiation strategy.
Issue: SPR-13658
This commit updates the WEBJARS_LOCATION in WebJarResourceResolver to
avoid getting duplicate slashes in resolved resources locations such
as `/webjars//bootstrap/3.3.2/js/bootstrap.min.js`.
Issue: SPR-14018
There is now an HttpCookie (simple name-value pair) and separately a
ServerHttpCookie sub-class with additional attributes that a server
can send to clients.
HttpHeaders is no longer the place to access cookies. Instead there is
a read-only HttpCookie map on ServerHttpRequest and a mutable
ServerHttpCookie map on ServerHttpResponse.
Cookies are stored in a map that preserves their order.
The DefaulUriTemplateHandler now provides a strictEncoding property
which if turned on encodes everything outside the reserved char set.
This is in contrast to the default policy of encoding only illegal
charaters depending on the URI component type.
Issue: SPR-11652
This commit adds a newline char at the beginning of textarea tags
values. As per the HTML 4.01 spec (and browsers behavior), a line break
following a start tag is ignored.
This can lead to Spring's textarea tag to ignore a line break char at
the beginning of a tag value.
See https://www.w3.org/TR/html401/appendix/notes.html#notes-line-breaks
Issue: SPR-13503
This commit changes the visibility of the getTestContext() method in
TestContextManager from 'protected' to 'public' in order to support
test method injection in JUnit 5 and similar use cases.
Issue: SPR-14011
Prior to this change, SPR-13867 made sure that any class extending
WebContentGenerator would not overwrite existing HTTP "Cache-Control"
response headers - set by a filter, a Controller handler, etc.
This caused issues with resource handling, since specifying a cache
configuration there would not overwrite default headers set by filters,
for example by Spring Security.
This commit restricts the previous changes to the
RequestMappingHandlerAdapter, in order to avoid overwriting header set
by a filter or a Controller handler in those cases.
Issue: SPR-14005
This commit demonstrates how to register one or more @Configuration
classes via an ApplicationContextInitializer in a composed annotation so
that certain @Configuration classes are always registered whenever the
composed annotation is used, even if the composed annotation is used to
declare additional @Configuration classes.
The new Filter is simply a new way of packaging the ability to extract
X-Forwarded-* headers already available via UriComponentsBuilder.
The Filter wraps the request and the effect is that anything using the
request will see the original schem, host, and port.
Issue: SPR-13614
Prior to this commit, `ServletWebRequest.checkNotModified` would only
support conditional GET/HEAD requests with "If-Modified-Since" and/or
"If-None-Match" request headers. In those cases, the server would return
"HTTP 304 Not Modified" responses if the resource didn't change.
This commit adds support for conditional update requests, such as
POST/PUT/DELETE requests with "If-Unmodified-Since" request headers.
If the underlying resource has been modified since the specified date,
the server will return a "409 Precondition failed" response status
to prevent concurrent updates.
Even if the modification status of the resource is reversed here
(modified vs. not modified), we're keeping here the same intent for the
return value, which signals if the response requires more processing or
if the handler method can return immediately:
```
if (request.checkNotModified(lastModified)) {
// shortcut exit - no further processing necessary
return null;
}
```
Issue: SPR-13863
Before this commit, specifying the charset to use with produces or
consumes @RequestMapping attributes resulted in default charset
loss. That was really annoying for JSON for example, where using
UTF-8 charset is mandatory in a lot of use cases.
This commit adds a defaultCharset property to
AbstractHttpMessageConverter in order to avoid losing the
default charset when specifying the charset with these
@RequestMapping attributes.
It changes slightly the default behavior (that's why we have waited
4.3), but it is much more error prone, and will match with most
user's expectations since the charset loss was accidental in most
use cases (users usually just want to limit the media type supported
by a specific handler method).
Issue: SPR-13631
This commit introduces the following common composed annotations for
@RequestMapping in Spring MVC and Spring MVC REST.
- @GetMapping
- @PostMapping
- @PutMapping
- @DeleteMapping
- @PatchMapping
Issue: SPR-13992
Prior to this commit, the TransactionalTestExecutionListener required
@Transactional test methods to be public; however, neither TestNG nor
JUnit 5 require that @Test methods are public. Consequently, non-public
transactional test methods silently run *without* a transaction.
This commit removes the 'public' restriction on transactional test
methods by setting the 'publicMethodsOnly' flag in
AnnotationTransactionAttributeSource to false.
Issue: SPR-14000
In order to align with the relaxed programming models of TestNG and the
upcoming JUnit 5 (with regard to method visibility), this commit
removes the requirement that @BeforeTransaction and @AfterTransaction
methods must be 'public'.
Issue: SPR-13997
This commit introduces a SpringRunner extension of
SpringJUnit4ClassRunner that is intended to be used as an 'alias' for
SpringJUnit4ClassRunner, primarily in order to simplify configuration
of JUnit 4 based integration tests.
Developers can use this alias as follows:
@RunWith(SpringRunner.class)
public class MySpringIntegrationTests { ... }
Issue: SPR-13954
MockRestServiceServer now provides static methods for builder-style
creation of MockRestServiceServer. This includes an option ignore
the order of declaration expected requests.
Issue: SPR-11365
This commit factors out the logic to declare and manage expectations
including matching them to requests and verifying at the end behind
a commong abstraction.
MockRestServiceServer delegates to the new abstraction and is no longer
aware of how that's done. There are two implementations, one for
ordered and another for unordered expectation.
Issue: SPR-11365
Before this commit RequestMatcherClientHttpRequest served both as
API to define request expectations, i.e. ResponseActions, as well as
the implementation of ClientHttpRequest representing actual requests.
DefaultResponseActions replaces this class as a simple holder of
expected requests and mock responses. MockRestServiceServer is then
responsible to match request expectations and create a mock response.
Issue: SPR-11365
Claneup of the Servlet 3.1 support:
- moved RequestBodyPublisher to ServletServerHttpRequest
- moved ResponseBodySubscribera to ServletServerHttpResponse
- response body is now copied to ServletOutputStream in chunks, rather
than one big byte[]
The CORS pre-flight request matching logic for all request conditions
was added (in 4.2) to RequestMappingInfo. However the logic for
default handling of all HTTP OPTIONS requests for 4.3 unintentionally
overrode some of the pre-flight request handling thus causing issues.
This commit moves CORS pre-flight matching logic into each respective
RequestMethodCondition implementations so each has to consider in one
place what happens for pre-flight and for all other requests.
Issue: SPR-13130
Previously, a ConfigurationClass created from AnnotationMetadata
and a ConfigurationClass created from a class would have subtly
different descriptions. Given a class named com.example.Foo, the
former’s description would be “com.example.Foo”, whereas the latter’s
description would be “class com.example.Foo”.
This commit updates ConfigurationClass to make the description
consistent, preferring the description without “class” in it.
Closes gh-970
The test failure was caused by the previous commit. The Message
resolver now supports payload conversion so it can raise a
MessageConversionException, not MethodArgumentTypeMismatchException.
Refine the optimizations made in 6f55ab69 in order to restore binary
compatibility and resolve a regression.
Tests of the form pathMatcher.match("/foo/bar/**", "/foo/bar") should
return true as this was the behavior in Spring 4.2.
Issue: SPR-13913
The MessageMethodArgumentResolver now also supports applying a
MessageConverter to the payload.
This is effectively a shortcut for declaring a method with an @Payload
argument + MessageHeaders and then creating a new message from the two.
Issue: SPR-13288
Commit ccd17d introduced a regression where a custom HTTP method
would no longer match for an empty @RequestMapping condition.
The previous behavior should now be restored. Effectively
RequestMethodRequestCondition as before will now match to any HTTP
method (even unknown/custom ones) if the methods condition is empty.
The only exception is HTTP OPTIONS for which we provide default
handling as a fallback (i.e. when not mapped explicitly).
Issue: SPR-13130
This commit adds weak ETag support in ShallowEtagHeaderFilter.
This improves the behavior of the filter in tow ways:
* weak ETags in request headers such as `W/"0badc0ffee"` will be
compared with a "weak comparison" (matching both weak and strong ETags
of the same value)
* when enabled with the "writeWeakETag" init param, the filter will
write weak Etags in its HTTP responses
Issue: SPR-13778
This change makes clear that this is the intent of the CacheControl API
not to provide a way to configure both "no-cache" and "no-store"
directives for the "Cache-Control" header.
Issue: SPR-13780
Check that the path is valid and resolvable before checking that the
http method is supported. For invalid or unresolvable paths, always
respond with a 404.
This commit changes the OkHttpClientHttpRequestFactory to use the
synchronous OkHttp API for non-async requests, as opposed to
synchronizing the async API (which it used to do).
Issue: SPR-13942
This commit speeds up the AntPathMatcher implementation by
pre-processing patterns and checking that candidates are likely
matches if they start with the static prefix of the pattern.
Those changes can result in a small performance penalty for positive
matches, but with a significant boost for checking candidates that don't
match. Overall, this tradeoff is acceptable since this feature is often
used to select a few matching patterns in a much bigger list.
This will lead to small but consistent performance improvements in
Spring MVC when matching a given request with the available routes.
Issue: SPR-13913
This commit adds a View and ViewResolver contracts to support HTML
template based rendering.
ViewResolverResultHandler applies view resolution by iterating the
resolvers to resolve to a view and then use it to render.
A model is created and passed to argument resolvers including a new
ModelArgumentResolver. The model is then exposed for result handling
as a field in HandlerResult.
Rename result to returnValue and resultType to returnValueType to
reflect what they represent.
The returnValue getter is also wrapped as Optional since the value
returned from a handler may be null (e.g. void method, null value).
Before this commit the concurrent session wrapper mainly protected the
sending of messages. The close itself however may also cause a message
to be sent as is the case of the SockJS protocol.
This change protects the close and checks if the session has exceeded
send time or buffer limits in which case the close status is changed
to SESSION_NOT_RELIABLE (introduced in commit cbd5af3a) which in turn
signals that extra care should be exercised when closing the session.
Issue: SPR-13904
This turned into the extraction of a common AbstractResourceBasedMessageSource base class which not only features addBasenames but also getBasenameSet and setCacheMillis.
Issue: SPR-10314
Prior to this commit, the transaction manager and data source look-up
algorithms in the Spring TestContext Framework were not capable of
retrieving 'primary' beans of those types, even though 'primary' beans
are supported in production as well as for injecting dependencies into
test instances. Specifically, if there was more than one transaction
manager or data source bean and one of them was flagged as 'primary',
the retrieveTransactionManager() and retrieveDataSource() methods in
TestContextTransactionUtils would simply return null for such beans.
This commit updates TestContextTransactionUtils by adding support for
looking up primary transaction managers and data sources.
Issue: SPR-13891
Prior to this commit, a @Transactional integration test would silently
be executed without a transaction if the transaction manager could not
be retrieved from the application context -- for example, it no such
bean was defined or if multiple beans were present but none satisfied
the qualifier.
This commit addresses this issue by throwing an IllegalStateException
if the PlatformTransactionManager cannot be retrieved for a
@Transactional test.
Issue: SPR-13895
This commit adds `RxJava1WebResponseExtractors`, a static factory of
`WebResponseExtractor`s that are based on the RxJava1 composition API.
All extracted types are based on the `Single` and `Observable` types.
This commit adds the `WebClient`, which relies on several parts of our
infrastructure:
* a `ClientHttpRequestFactory` to drive the underlying client library
* a `HttpRequestBuilder` builder API to create the client request
* a `WebResponseExtractor` to extract the "low-level"
`ClientHttpResponse` into a higher level representation such as a
decoded body
The `WebResponseExtractors` helper class contains many extractor
implementations all based on the `Flux`/`Mono` composition API.
This commit adds the `ClientHttpRequest` and `ClientHttpResponse`
implementations for the RxNetty HTTP client.
This client library is based on the `Single` and `Observable`
composition API, so this has to be converted to the `Flux`/`Mono`
variants.
This commit introduces the `ClientHttpRequest` and `ClientHttpResponse`
implementations for the Reactor-Net HTTP client. This client is already
based on the `Flux` and `Mono` contracts.
This commit also adds a `AbstractClientHttpRequest` to support the
`ClientHttpRequest` implementations; it mirrors the
`AbstractServerHttpResponse` contract with a `beforeCommit` to register
`Supplier`s that should be notified before the request is committed.
This commit adds a `DefaultHttpRequestBuilder` and its companion static
builders in `HttpRequestBuilders`. This allows to build client requests
with a friendly builder API, inspired by Spring's MockMvc API.
This commit adds the base contracts for the Web client.
The "Reactive" prefixes of the previously commited contracts has been
removed to match the server ones.
Both the `ClientHttpRequest` and the `ServerHttpResponse` extend
`ReactiveHttpOutputMessage`, which now has a `beforeCommit` method,
necessary in both client and server implementations.
`HttpRequestBuilder` will be used by the developers to create requests
with a nice builder API. `ClientHttpRequestFactory` will provide support
for many HTTP client libraries in this new client.
Custom argument resolvers configured in the MVC Java config or the
MVC namespace are now injected in both the RequestMappingHandlerAdapter
as well as in the ExceptionHandlerExceptionResolver.
Issue: SPR-12058
WebServerExchange -> ServerWebExchange
Follows the same convention as in the http package also better allowing
the possibility for a client equivalent in the future.
WebToHttpHandlerBuilder -> WebHttpHandlerBuilder
WebToHttpHandlerAdapter -> WebHttpHandlerAdapter
More consistent with Spring conventions.
Introduce adapter and handler sub-packages under web.server following a
review prompted by the addition of the session package and the package
cycle it brought in based on dependency on session.WebSessionManager.
This commit adds initial support for a maintaining a server-side
session with attributes across HTTP requests. The WebSession
abstraction can be accessed via WebServerExchange from a WebFilter or
the target WebHandler.
The session sub-package contains additional abstractions for creating
and managing sessions providing a basis for extensibility (e.g. Spring
Session). Those include WebSessionManager, SessionIdStrategy, and
SessionStore along with a cookie-based session id strategy and an
in-memory session store in use by default.
Note that the current API does not provide a way to invalidate or
re-create the session from server side code.
setComplete replaces writeHeaders as a more general lifecycle method
to perform any kind of handling at the end of request processing, for
example to ensure headers are written if not already.
beforeCommit provides an extension point for an action to be invoked
just before the response is committed, e.g. adding headers/cookies.
Added DataBuffer and DataBufferAllocator, and provided a default NIO
ByteBuffer-based implementation of those, as well as a Netty
ByteBuf-based version.
Since the build has been upgraded to Gradle 2.10, it's showing the
following message:
"The 'sonar-runner' plugin has been deprecated and is scheduled to be
removed in Gradle 3.0. please use the official plugin from SonarQube"
This commit makes use of the "org.sonarqube" Gradle plugin and uprgrades
the Jacoco agent version to 0.7.5.
See: https://sonar.spring.io/updatecenter/updates
See: https://jira.sonarsource.com/browse/SONARJAVA-1091
Closes gh-949
This is in line with the current behavior of HttpServlet that would
have been in used with dispatchOptionsRequest on the DispatcherSerlvet
set to false (the default prior to 4.3).
Issue: SPR-13130
The WebContentGenerator now maintains an additional property that
sub-classes can use for an "Allow" header in response to an HTTP
OPTIONS request. This property is pre-initialized once at startup
and does not have to rely on getSupportedMethods in addition to
adding HTTP OPTIONS if not explicitly listed.
Issue: SPR-13130
AbstractJackson2HttpMessageConverter now implements its own
TypeVariable resolution algorithm since in Jackson 2.7 it is now
deprecated and has not the same behavior .
See https://github.com/FasterXML/jackson-databind/issues/1087
for more details.
The dependency on jackson-datatype-jdk7 has been removed since
it is now provided by default in the jackson-databind module.
Issues: SPR-13483, SPR-13728
This commit updates the javadoc of
`RequestMappingHanderAdapter.setCacheSecondsForSessionAttributeHandlers`
to explain how one can disable that feature and prevent "Cache-Control"
directives from being added when `@SessionAttributes` annotations are
used on Controllers.
Issue: SPR-13598
Prior to this change, configuring a `FixedVersionStrategy` like so
would configure a single "/js/**" path pattern:
```
versionResourceResolver.addFixedVersionStrategy("v1.0.0","/js/**");
```
This commit makes sure that for each path pattern, its prefixed version
is added to the map. For example, the previous configuration also
adds "/v1.0.0/js/**".
Issue: SPR-13883
Prior to this change, the `RequestMappingHandlerAdapter` would first add
a "Cache-Control" HTTP header to the response (depending on its
`WebContentGenerator` configuration and `@SessionAttributes` on the
handler class); then, the Adapter would delegate the actual handler the
processing of the request.
This leads to issues, as the handler does not have full control to the
response and has to deal with pre-existing headers in the response. This
means that the Adapter and the handler can add incompatible
Cache-Control directives without knowing it, since one cannot see the
headers added by the other until the response is committed.
This commit switches the order of execution: first, the handler is
called (possibly adding HTTP headers), then the RMHA processes the
response and adds "Cache-Control" directives *only if there's no
Cache-Control header already defined*.
Issue: SPR-13867
This change exposes protected methods for instantiating sub-classes of
RequestMappingHandlerAdapter and ExceptonHandlerExceptionResolver
similar to the existing method for RequestMappingHandlerMapping.
Prior to this change SpEL did not have an syntactic
construct enabling easy access to a FactoryBean. With this
change it is now possible to use &foo in an expression when
the factory bean should be returned.
Issue: SPR-9511
Spring MVC Test now parses application/x-www-form-urlencoded request
content and populates request parameters from it.
This can be useful when running client-side tests against a MockMvc
via MockMvcClientHttpRequestFactory.
Issue: SPR-13733
Prior to this change, the `ResourceUrlEncodingFilter` would try to
lookup resources URLs as soon as the given URL would be longer than the
expected context+servlet prefix path. This can lead to
OutOfBoundsExceptions when the provided URL does not start with that
prefix and still has the required length.
This commit makes sure that all candidate URLs for resources lookup are
prefixed with the cached servlet and context path. This underlines the
fact that the `ResourceUrlEncodingFilter` does not support relative URLs
for now and delegates to the native servlet implementation in that case.
Issue: SPR-13861
Prior to this commit, Spring MVC Test only supported HTTP methods GET,
POST, HEAD, OPTIONS, PUT, PATCH, DELETE, TRACE and multipart file
upload. This change adds generic methods to MockMvcRequestBuilders in
order to allow testing of arbitrary HTTP methods in a Spring MVC
application.
Issue: SPR-13719
This commit allows to create a Quartz trigger implementation via
either `CronTriggerFactoryBean` or `SimpleTriggerFactoryBean` even if no
job detail is provided.
Issue: SPR-13604
Previously, if a database needs to be initialized with several scripts
and many (or all) use a custom separator, said separator must be repeated
for each script.
This commit introduces a `separator` property at the parent element level
that can be used to customize the default separator. This is available
for both the `initialize-database` and `embedded-database` elements.
Issue: SPR-13792
Support of @JsonView on @JmsListener annotated method that uses the
jackson converter. Also update MappingJackson2MessageConverter to offer
a public API to set the JSON view to use to serialize a payload.
Issue: SPR-13237
This change updates all cases where callbacks are invoked to catch and
suppress errors (since there is not match to do with and error from
a callback be it success or failure).
Also updated is the contract itself to clarify this and emphasize the
callbacks are really notifications for the outcome of the
ListenableFuture not the callbacks themselves.
Issue: SPR-13785
Before this change AsyncRestTemplate had two anonymous implementations
of ListenableFuture that were adapting the result. Those have been
replaces with ListenableFutureAdapter.
This commit is preparation for SPR-13785.
Previously, any `javax.jms.Message` was converted eagerly to the Message
abstraction. This leads to unnecessary conversion if the Payload is not
requested by the underlying method (i.e. if the `javax.jms.Message` is
injected directly).
This commit returns a `Message` implementation that holds the
`javax.jms.Message` and lazily resolve the payload or the headers on
demand (that is the first time they are requested).
Issue: SPR-13777
Before this change use of ExceptionHandlingWebHandler did ensure no
error signals are allowed to escape (hence relying on runtime
behavior).
This change ensures the same is done even when
ExceptionHandlingWebHandler is not configured for use, at the lowest
level which is the WebToHttpHandlerAdapter.
When decoding buffers as plain strings, the StringDecoder returns a
Publisher that may produce one or more `onNext` events.
This is perfectly valid, but leads to errors when trying to convert the
resulting Publisher into a `reactor.Mono` or `rx.Single`.
If the original Publisher emits 2 or more `onNext` signals,
converting to:
* `rx.Single` will throw an error saying that the underlying Observable
"emitted too many elements"
* `reactor.Mono` may contain only the first emitted element
This commit adds a `AbstractRawByteStreamDecoder` that takes a
`SubscriberBarrier` to apply splitting/aggregation operations on the
received elements.
The `StringDecoder` class now inherits from this abstract class and
uses one of the provided `SubscriberBarrier` implementations to
buffer all received elements in a single buffer.
Before this commit, a handler method returning a stream with a JSON
content-type was producing a JSON object for single element streams
or a JSON array for multiple elements streams.
This kind of dynamic change of the output based on the number of
elements was difficult to handle on client side and not consistent
with Spring MVC behavior.
With this commit, we achieve a more consistent behavior by using
the Mono semantics to control this behavior. Mono (and Promise/Single)
are serialized to JSON object and Flux (and Observable/Stream) are
serialized to JSON array.
HttpCookie is now immutable with factory methods to create a client
cookie (name-value) vs a server cookie (name-value + attributes)
including a builder for the latter.
This commit brings back the writeHeaders method on ServerHttpResponse
that was once added (2a6a4f) and then removed (9c7151).
This version is a little simpler since writeHeaders doesn't explicitly
flush/send headers which runtimes are expected to do by default.
Instead the main purpose of writeHeaders now is to ensure changes made
via HttpHeaders are applied to the underlying runtime response at some
point and we now do that once at the very end.
This approach provides the most flexibility (vs keeping HttpHeaders in
sync) because it allows a full and consistent set of mutative
operations for both headers and cookies (to be added) regardless of the
API exposed by the underlying runtime.
This change adds a WebServerExchange and updates all contracts at the
the same level (i.e. org.springframework.web.server) as well as the
org.springframework.web.reactive level to use it so that all
framework-related code will have access to server-side processing
features such as request attributes (and others to come).
This change separates out lower-level HTTP adapter code from the more
(framework-specific) HTTP processing into a separate package under
org.springframework.web.server (not under org.springframework.http).
Flux and Mono are used both for implementation and exposed at API
level to express 1 versus N semantic and to provide default Rx
operators:
- Flux<T> for multiple values Publisher (issue #48)
- Mono<T> for single value Publisher (issue #50)
- Mono<Void> for Publisher with no value (issue #49)
Prior to this change, a resource handler chain configured with a
`VersionResourceResolver` would add the resource version to the request
attributes when serving that resource. This approach would not work when
a `CachingResourceResolver` is configured and the resource is already
cached. Indeed, that code path is not executed when the resource is
resolved from the cache.
This commit adds a new `VersionedResource` interface that's used by the
`VersionResourceResolver`, adding a `getVersion()` method that returns
the version string for that resource. This way, the version information
is cached with the resource itself and the request attributes are no
longer used for this.
Issue: SPR-13817
For those runtimes that don't directly support Reacitve Streams this
commit separates more formally Reactive Streams bridge code out of
the request and response implementations which become simple adapters
to the ServerHttpRequest/Response contracts like their RxNetty and
Reactor Net counterparts.
ServerHttpResponse implementations now immediately propagate
HttpHeaders changes as they so there is no need to call applyHeaders().
The writeHeaders from ServerHttpResponse is also removed. RxNetty and
Reactor Net both support implicitly completing if the handler
completes without explicitly writing the headers or the response body.
Since ListenableFuture callbacks are invoked after the future is set,
we cannot rely on callbacks having taken place right after a call
to future.get(). This change adds a CountdownLatch to detect when
the callbacks were invoked.
Issue: SPR-12538
AsyncRequestExecution now properly supports decoration of the
request (URI, HTTP method, and headers).
Removed a no-op IdentityListenableFutureAdapter.
Use Spring Framework coding style.
Issue: SPR-12538
ConcurrentMapCacheManager and ConcurrentMapCache now support the
serialization of cache entries via a new `storeByValue` attribute. If it is
explicitly enabled, the cache value is first serialized and that content
is stored in the cache.
The net result is that any further change made on the object returned
from the annotated method is not applied on the copy held in the cache.
Issue: SPR-13758
Previously, if a `@Cacheable` method was accessed with the same key by
multiple threads, the underlying method was invoked several times instead
of blocking the threads while the value is computed. This scenario
typically affects users that enable caching to avoid calling a costly
method too often. When said method can be invoked by an arbitrary number
of clients on startup, caching has close to no effect.
This commit adds a new method on `Cache` that implements the read-through
pattern:
```
<T> T get(Object key, Callable<T> valueLoader);
```
If an entry for a given key is not found, the specified `Callable` is
invoked to "load" the value and cache it before returning it to the
caller. Because the entire operation is managed by the underlying cache
provider, it is much more easier to guarantee that the loader (e.g. the
annotated method) will be called only once in case of concurrent access.
A new `sync` attribute to the `@Cacheable` annotation has been addded.
When this flag is enabled, the caching abstraction invokes the new
`Cache` method define above. This new mode bring a set of limitations:
* It can't be combined with other cache operations
* Only one `@Cacheable` operation can be specified
* Only one cache is allowed
* `condition` and `unless` attribute are not supported
The rationale behind those limitations is that the underlying Cache is
taking care of the actual caching operation so we can't really apply
any SpEL or multiple caches handling there.
Issue: SPR-9254
Previously, if a managed bean had only one non-default constructor, we
should still annotate it with `@Autowired` to properly use constructor
injection. Not doing so resulted in an error as the container was
trying to call the default (non-existing) constructor.
This commit updates this behaviour to automatically applyed the
autowiring semantic to any bean that has only one constructor. As
before, if more than one constructor is defined, `@Autowired` must be
specified to teach the container the constructor it has to use.
Issue: SPR-12278
In several places in the spring-webmvc module, URL patterns / objects
relationships are kept in `HashMap`s. When matching with actual URLs,
the algorithm uses a pattern comparator to sort the matching patterns
and select the most specific. But the underlying collection
implementation does not keep the original order which can lead to
inconsistencies.
This commit changes the underlying collection implementation to
`LinkedHashmap`s, in order to keep the insert order if the comparator
does not reorder entries.
Issue: SPR-13798
The DispatcherHandler now has an errorMapper property that is a
function for transforming errors. By default this property is set to an
instance of DispatcherHandlerExceptionMapper which wraps "standard"
framework exceptions and @ResponseStatus-annotated exceptions as
ResponseStatusException.
This makes it easy to handle the exceptions downstream uniformly.
This change adds a ResponseStatusException to associate an exception
with a status code at runtime. Along with that is an
ResponseStatusExceptionHandler that handles ResponseStatusException
by setting the response status.
Before this change the compilation of a method reference or property/field
access was not properly cleaning up the stack if compilation meant
calling a static method or accessing a static field. In these cases there
is no need for a target object on the stack and it should be removed if
present. For a simple expression it is harmless since the end result of
the expression is the thing on the top of the stack, but for nested
expressions if the inner expression suffered this issue, the outer
expression can find itself operating on the wrong element.
The particular issue covered the case of a static field access but this
fix (and associated tests) cover static method, property and field access.
Issue: SPR-13781
JIRA: https://jira.spring.io/browse/SPR-13784
JDK8 and Apache Commons Codec support the RFC 4648
"URL and Filename Safe" Base64 alphabet.
Add methods to `Base64Utils` to support this feature.
General improvements e.g. make use of Java 8 Stream. The main reason
for the refactoring however to tighten error handling. To that extent:
InvocableHandlerMethod turns all exceptions into Reactive Streams
error signals, in effect never allowing any Exceptions to bubble up.
HandlerMethodArgumentResolver may throw an Exception for sync resolution
or produce an error signal via the returned Publisher. Either way the
exception is consistently wrapped with helpful method argument details.
For the latter case using a custom mapError operator.
HandlerMethodArgumentResolver no longer needs to return Optional for
nullable argument values. Instead (for now) the defaultIfEmpty operator
of reactor.rx.Stream operator is used to ensure a default constant value
(called "NO_VALUE") is produced. That way an argument resolver may
produce 0..1 values where 0 means it did not resolve to any value and
that results in null passed as the argument value.
If a HandlerMethodArgumentResolver produces more than one value, all
additional values beyond the first one will be ignored with the help
of a custom "first" operator.
As HandlerMethod is invoked within the map operator, checked exceptions
are not allowed but instead of wrapping it in a runtime exception what
we really need is to unwrap the target exception for exception
resolution purposes. To this end concatMap is used to produce a nested
Publisher or an error Publisher with the unwrapped target exception.
Related to that InvocableHandlerMethod now returns
Publisher<HandlerResult> instead of Publisher<Object> so that no longer
needs to be externally mapped from Object to HandlerResult.
InvocableHandlerMethodTests provides tests for the above scenarios and
verifies the details of resulting error signals.
This change also removes reactor-stream variants of the request and
response since the request and response aren't used directly by
application code and get passed through reactor.Publishers anyway.
Fixed a bug where the URL content negotiation "format" parameter values
were case sensitive and only lowercase values were accepted. For
example, URL query parameter format=json returned the appropriate JSON
response but format=JSON resulted in a
HttpMediaTypeNotAcceptableException and returned:
406 - The resource identified by this request is only capable of
generating responses with characteristics not acceptable according to
the request "accept" headers.
When the MappingMediaTypeFileExtensionResolver is constructed, it is
passed a map containing the media type key to MediaType mappings
defined in the ContentNegotiationConfigurer. In the constructor of
MappingMediaTypeFileExtensionResolver, the keys are converted to
lowercase and the mappings of keys to MediaTypes are added to the
ConcurrentMap<String, MediaType> mediaTypes using the lowercase
version of the keys. However, when retrieving the MediaType from a key
in the lookupMediaType method, no conversion to lowercase is performed
so any value for the URL "format" parameter other than the lowercase
version will not return the proper MediaType result.
On May 1st, 2014, a change was made to
ParameterContentNegotiationStrategy to handle cases where the content
negotiation format URL parameter does not result in a match for a
MediaType. If no match is found, a HttpMediaTypeNotAcceptableException
is thrown resulting in the 406 response above. Prior to this commit, a
null was returned instead of throwing an exception so this issue was
hidden and appeared to function correctly.
To make the media type lookup case insensitive, added a line to the
lookupMediaType method in MediaTypeFileExtensionResolver to first
convert the extension (media type key) to lowercase prior to attempting
to retrieve it from the mediaTypes map.
Issue: SPR-13747
This commit reworks the arrangement to a centralized cache, avoiding any extra reflection attempts if a cache entry is known already. In the course of this, it also enforces toXXX methods to be declared as non-static now (which is the only sensible arrangement anyway).
Issue: SPR-13703
Prior to this change, the resource handling FixedVersionStrategy would
be applied on all links that match the configured pattern. This is
problematic for relative links and can lead to rewritten links such as
"/fixedversion/../css/main.css" which breaks.
This commit prevents that Strategy from being applied to such links.
Of course, one should avoid to use that VersionStrategy with relative
links, but this change aims at not breaking existing links even if it
means not prefixing the version as expected.
Issue: SPR-13727
The recent commit 971f04 replaced the use of a NAMES_PATTERN regex in
favor of direct parsing in order to deal with nested curly braces.
The change also incorrectly replicated this logic which removes a
trailing slash after Pattern quoting (and not before):
https://github.com/spring-projects/spring-framework/blob/cca037a74df9b87f99858154b47696a9eccf69c8/spring-web/src/main/java/org/springframework/web/util/UriTemplate.java#L207-L210
After some more investigation there doesn't appear to be any scenario
where the quoted pattern would end with a trailing slash. It should
always end with \E (end of quote) or a ")" (end of group). Nor are
there any failing tests so this commit removes the logic altogether.
Issue: SPR-13705
This commit refines getMergedBeanDefinition's scope adaptation algorithm for inner beans, never leaving a custom scope within a containing bean of a different scope. The inner bean's scope will either be aligned with the containing bean's scope (matching the effective state) or be switched to prototype in case of an outer singleton (indicating that no singleton state management is desired).
Issue: SPR-13739
Also switches 4.2.4's new formatter implementations to package visibility, just in case they'll be superseded by another variant in the future.
Issue: SPR-13730
When the plus operator is used between strings in a SpEL
expression and that expression is compiled, it is
important to include a cast if computation of any of
the operands isn't obviously leaving strings on the
stack. Likewise if the stack contents are known to
be strings, a cast should not be included.
Issue: SPR-12426
Prior to this commit, range requests would be served by
ResourceHttpRequestHandler by partially reading the inputstream of
static resources. In case of resources contained in ZIP/JAR containers,
InputStreams may not fill the entire read buffer when calling
`inputStream.read(byte[])`. This was the case when using Spring Boot's
ZipInflaterInputStream - this would then not read the entire file
content and would close the response without writing the expected body
length indicated in the "Content-Length" header.
This commit makes sure that the whole resource is read.
Issue: SPR-13661
This is needed in order to be able to use Spring Reactive in standalone
applications. These are temporary classes that will return in
src/test/java when Spring Boot support for Reactive applications will
be implemented.
Prior to this commit, when adding a ShallowEtagHeaderFilter to an
application, the ServletResponse would be wrapped by a
ContentCachingResponseWrapper. When any part of the Spring
infrastructure calls `flushBuffer` on the wrapped response, the call is
delegated to the actual response, which is committed. It's not possible
to alter the response (headers, content) anymore - the ETag filter can't
act.
This change prevents the `flushBuffer` call to be delegated and only
commits the underlying response once the cached content is copied to the
actual response stream.
Issue: SPR-13717
With this change the MapAccessor now extends CompilablePropertyAccessor
rather than just PropertyAccessor. This means that any expression that
ends up using the MapAccessor is now compilable for fast performance.
Issue: SPR-13638
reactive.codec -> core.codec
reactive.io -> util
These may very well not be the final locations. For now they simply
express that there are classes that belong somewhere in core, i.e.
they are lower level dependencies than web.
RequestMappingHandlerMapping currently picks the first match and does
have logic to deal with selecting the best match. This caused a
random test failure depending on which controller method was matched
first. This change removes the test.
The web related code is now under org.springframework.web.reactive.
This is parallel to org.springframework.web (the top-level package of
spring-webmvc).
This change allows to be able to check generic type on the return value
at HandlerAdapter and ResultHandler level. For example, it allows to do
a Publisher<Void> check in SimpleHandlerResultHandler.
"Content-Type" is just a single MediaType.
For the response, the MediaType must be fully selected before
selecting and encoder.
The ResponseBodyResultHandler now includes actual content negotiation
with a potential 406 response.
This commit introduces the following changes:
- MessageToByteEncoder/Decoder renamed to Encoder/Decoder
- JsonObjectEncoder/Decoder are now used directly in
JacksonJsonEncoder/Decoder
- Codec uses MimeType instead of MediaType since they
are not specific to HTTP
- Default MimeType are now managed thanks to
Encoder/Decoder#getSupportedMimeTypes()
- AbstractEncoder/Decoder takes care of generic MimeType related behavior
Even though the JSR-107 spec forbids to store null values, our cache
abstraction allows that behaviour with a special handled (and this is
the default behaviour).
While this was working fine with our own set of annotations, the
JSR-107 interceptor counterpart was interpreting the spec sensu strictu.
We now allow for that special case as well.
Issue: SPR-13641
This commit expands the range of whitelisted extensions by checking
if an extension can be resolved to image/*, audo/*, video/*, as well
as any content type that ends with +xml.
Issue: SPR-13643
Prior to this change, the HttpEntityMethodProcessor would try to process
conditional requests that are undefined by the spec, such as:
* an HTTP GET request with "If-None-Match:*"
* a request with both "If-None-Match" and "If-Match"
* a request with both "If-None-Match" and "If-Unmodified-Since"
This commit skips the processing of those requests as conditional
requests and continues with normal request handling.
Issue: SPR-13626
The URI template is now manually parsed vs using a regex to extract
URI variable names and to create a pattern for matching to actual URLs.
This provides more control to deal with nested curly braces.
Issue: SPR-13627
The goal is to avoid String name comparisons in favor of annotation type identity checks wherever possible. Also, we avoid double getDeclaredAnnotations/getAnnotations checks on anything other than Classes now, since we'd just get the same result in a fresh array.
Issue: SPR-13621
Improve the performance of the `getMergedAnnotationAttributes` and
`isAnnotated` methods in `AnnotatedElementUtils` by returning
immediately when the element had no annotations.
Issue: SPR-13621
Add new MediaType.APPLICATION_JSON_UTF8 and
MediaType.APPLICATION_JSON_UTF8_VALUE constants for
"application/json;charset=UTF-8" content type in order to make it
easier to override @RequestMapping "produces" attribute without
losing the default JSON charset (UTF-8).
Issue: SPR-13600
Refine the approach of having <mvc:view-resolvers> detect and use the
ContentNegotiationManager instance registered with
<mvc:annotation-driven> introduced in the last commit.
Issue: SPR-13559
The <mvc:annotation-driven> element now adds an alias when a
ContentNegotiationManager bean is registered with a custom name.
This helps <mvc:view-resolvers> to more reliably find such a custom
ContentNegotiationManager.
Issue: SPR-13559
Prior to this change, serving resources with ResourceHttpRequestHandler
could result in NPE when requesting an existing folder located in a JAR.
This commit swallows those exceptions, as it is not possible to foresee
those cases without reading the actual resource. This result in a HTTP
200 response with a zero Content-Length instead of a HTTP 500 internal
exception.
Issue: SPR-13620
This commit introduces the following changes:
- Publisher -> Observable/Stream/etc. conversion is now managed
in a dedicated ConversionService instead of directly in
RequestBodyArgumentResolver and ResponseBodyResultHandler
- More isolated logic that decides if the stream should be
serialized as a JSON array or not
- Publisher<ByteBuffer> are now handled by regular
ByteBufferEncoder and ByteBufferDecoder
- Handle Publisher<Void> return value properly
- Ensure that the headers are properly written even for response
without body
- Improve JsonObjectEncoder to autodetect JSON arrays
Previously, the only way to add the collection converters to a registry
was to add *all* default converters. A new "addCollectionConverters"
public method is now available to only register them.
Issue: SPR-13618
When the cacheLimit is reached and there is an eviction from the
updateCache, the accessCache is now also updated.
This change also ensures that adding a destination to the cache is
protected with synchronization on the updateCache.
Issue: SPR-13555
As of Tyrus 1.9, `TyrusEndpointWrapper`'s constructor has a new Boolean
argument (which is mandatory).
This commit reflectively chooses the right constructor method for Tyrus
1.9+ versions.
Issue: SPR-13566
This commit removes duplicate slashes in the resolved lookup path when
calling `UrlPathHelper.getLookupPathForRequest`. This is especially
necessary when the path is cleaned from semicolon content and leaves
duplicate slashes in the request path.
Issue: SPR-13455
Replace Streams fail, empty and Stream map with Publishers.error, empty and map.
Replace Streams calls by Publishers.flatMap, just and Publishers.from
Precise cancel and size to toReadQueue to simulate Promise
Update build
The inner MimeTypeResolver class is no longer necessary in the
MockServletContext since the Java Activation Framework (JAF) is a
standard part of Java SE since Java 6.
Prior to this commit, HtmlUnitRequestBuilder stored empty query
parameters declared without an equals sign as null (i.e., query
parameters such as 'error' in 'http://example.com/login?error').
This commit addresses this issue by ensuring that
HtmlUnitRequestBuilder treats all empty query parameter values as empty
strings. Consequently, query strings such as '?error' and '?error=' now
both result in 'error' being stored as an empty string.
Issue: SPR-13524
This commit updates HandlerAdapter#handle() to return HandlerResult
instead of Publisher<HandlerResult>. A new SimpleHandlerResultHandler
class has been introduced for handlers returning Publisher<Void>.
The Javadoc wrongly referred to a behaviour that is not (and should not
be) implemented. List items are split into indexed keys and the
comma-separated value is not retained.
Issues: SPR-13257
We can't compile directly against NettyClientSocketOptions method which
changed signatures in 2.0.6. This change ensures the method is invoked
reflectively instead.
Prior to this commit, HtmlUnitRequestBuilder would incorrectly attempt
to decode null values for query parameters (i.e., query parameters such
as 'error' in 'http://example.com/login?error') which resulted in a
NullPointerException since URLDecoder.decode() does not support null
values.
This commit fixes this issue by ensuring that HtmlUnitRequestBuilder
only attempts to decode non-null query parameter values.
Issue: SPR-13524
SpringJUnit4ClassRunner, SpringClassRule, and SpringMethodRule now
throw an IllegalStateException with a meaningful message if JUnit 4.9
is not present in the classpath (specifically if
org.junit.runners.model.MultipleFailureException cannot be loaded).
Issue: SPR-13521
This commit adds support for origins with a trailing slash or a path,
in order to avoid printing a stacktrace in the logs when
WebUtils#isSameOrigin(HttpRequest) parses such invalid Origin header
value.
Issue: SPR-13478
This commit migrates all remaining tests from JUnit 3 to JUnit 4, with
the exception of Spring's legacy JUnit 3.8 based testing framework that
is still in use in the spring-orm module.
Issue: SPR-13514
This commit introduces a new ScriptRenderException in order to:
- Print in the resulting error page the reason of the script failure
- Not print the whole stacktrace in the logs
The ScriptRenderException thrown in ScriptTemplateView#renderMergedOutputModel()
is wrapped into a ServletException in order to avoid printing 2 times the messages in
the logs (throwing directly a ScriptRenderException would make it wrapped in a
NestedServletException that contains a getMessage() override not needed in this
context)
Issue: SPR-13488
ResponseBodyEmitter now registers by default to receive callbacks
on timeout/completion and sets its internal "complete" flag to true
in order to prevent proactively further use of the emitter.
Issue: SPR-13498
Prior to this commit, HttpEntityMethodProcessor would process
conditional requests even if those aren't GET requests.
This is an issue for POST requests with "If-None-Match: *" headers and
many other use cases, which should not receive an HTTP 304 Not Modified
status in response.
This commit only triggers ETag/Last-Modified conditional requests bits
for GET requests.
Issue: SPR-13496
As of Undertow 1.3.0, several APIs have been changed: replacing Xnio's
Pool/Pooled references to Undertow's new ByteBufferPool abstraction.
This move has been made, as part of
https://issues.jboss.org/browse/UNDERTOW-522, to prepare deprecations in
the Xnio API.
This commit adds a new strategy to deal with both 1.0-1.2 and 1.3
Undertow generations.
Issue: SPR-13366
The MockHttpServletRequestBuilder now uses java.net.URI internally
rather than UriComponents.
This means that for the MockMvcRequestBuilders method variants that
accept a java.net.URI we can use it as is. The difference is almost
none but it does mean that you can create a URI with double slashes
(for testing purposes) and have it remain that way.
Issue: SPR-13435
Some converters (Jackson, Gson, Protobuf) already do this. It is now
also done in AbstractMessageConverterMethodArgumentResolver which
enforces a consistent behavior across controller method arguments.
Issue: SPR-12745
Also revised StandardScriptFactory for finer-grained template methods, added further configuration variants to StandardScriptEvaluator, and identified thread-local ScriptEngine instances in ScriptTemplateView by appropriate key.
Issue: SPR-13491
Issue: SPR-13487
This commit makes ThreadLocal<ScriptEngine> engineHolder ScriptTemplateView
field static in order to limit the maximum number of ScriptEngine instances
to the number of threads, regardless of the number of view instances.
Issue: SPR-13487
This commit introduces ignored, failing tests that demonstrate that the
@Cache* annotations are not yet supported as merged composed annotations.
Issue: SPR-13475
This commit introduces support for attribute overrides for
@ResponseStatus when @ResponseStatus is used as a meta-annotation on
a custom composed annotation.
Specifically, this commit migrates all code that looks up
@ResponseStatus from using AnnotationUtils.findAnnotation() to using
AnnotatedElementUtils.findMergedAnnotation().
Issue: SPR-13441
This commit adds support for Publisher based codecs that allows to convert
byte stream to object stream and vice & versa.
Jackson, JAXB2 and String codec implementations are provided.
After this change, with Nashorn it is possible to use either
render(template, model) or render(template, model, url).
With JRuby or Jython, specifying the 3 parameters is mandatory.
Issue: SPR-13453
This change adds a new `getDateHeader` method that converts date header
Strings to long values - making tests more readable.
This feature is also documented in the "what's new section" for 4.2.
Prior to this commit, requests with an empty body and no Content-Type
header set would fail with a HttpMediaTypeNotSupportedException when
mapped to a Controller method argument annotated with
@RequestBody(required=false).
In those cases, the server implementation considers with an
"application/octet-stream" content type and polls messageconverters for
conversion. If no messageconverter is able to process this request, a
HttpMediaTypeNotSupportedException is thrown.
This change makes sure that such exceptions are not thrown if the
incoming request has:
* no body
* no content-type header
In this case, a null value is returned.
Issue: SPR-13147
Includes a revision for consistent and defensive Servlet 3.0 method calls across Spring's web abstraction (in particular, also working in debug mode where method references may get resolved early, so ternary expressions are to be avoided).
Issue: SPR-13420
This commit improves the documentation in the reference manual for the
HtmlUnit & Selenium WebDriver integration in the Spring MVC Test
framework by mentioning the group and artifact IDs required for this
functionality.
Issue: SPR-13299
This commit picks up where 3eacb837c2
(SPR-13345) left off by adding support for transitive implicit aliases
configured via @AliasFor.
Issue: SPR-13405
Spring Framework 4.2 introduced support for aliases between annotation
attributes that fall into the following two categories.
1) Alias pairs: two attributes in the same annotation that use
@AliasFor to declare that they are explicit aliases for each other.
2) Meta-annotation attribute overrides: an attribute in one annotation
uses @AliasFor to declare that it is an explicit override of an
attribute in a meta-annotation.
However, the existing functionality fails to support the case where two
attributes in the same annotation both use @AliasFor to declare that
they are both explicit overrides of the same attribute in the same
meta-annotation. In such scenarios, one would intuitively assume that
two such attributes would be treated as "implicit" aliases for each
other, analogous to the existing support for explicit alias pairs.
Furthermore, an annotation may potentially declare multiple aliases
that are effectively a set of implicit aliases for each other.
This commit introduces support for implicit aliases configured via
@AliasFor through an extensive overhaul of the support for alias
lookups, validation, etc. Specifically, this commit includes the
following.
- Introduced isAnnotationMetaPresent() in AnnotationUtils.
- Introduced private AliasDescriptor class in AnnotationUtils in order
to encapsulate the parsing, validation, and comparison of both
explicit and implicit aliases configured via @AliasFor.
- Switched from single values for alias names to lists of alias names.
- Renamed getAliasedAttributeName() to getAliasedAttributeNames() in
AnnotationUtils.
- Converted alias map to contain lists of aliases in AnnotationUtils.
- Refactored the following to support multiple implicit aliases:
getRequiredAttributeWithAlias() in AnnotationAttributes,
AbstractAliasAwareAnnotationAttributeExtractor,
MapAnnotationAttributeExtractor, MergedAnnotationAttributesProcessor
in AnnotatedElementUtils, and postProcessAnnotationAttributes() in
AnnotationUtils.
- Introduced numerous tests for implicit alias support, including
AbstractAliasAwareAnnotationAttributeExtractorTestCase,
DefaultAnnotationAttributeExtractorTests, and
MapAnnotationAttributeExtractorTests.
- Updated Javadoc in @AliasFor regarding implicit aliases and in
AnnotationUtils regarding "meta-present".
Issue: SPR-13345
Prior to this commit, ServletWebRequest would call
HttpServletResponse.getStatus(), which is a Servlet 3.x method.
This commit checks if this method is available before calling it, thus
keeping Servlet 2.5 compatibility.
Issue: SPR-13396
Related to that, HibernateTransactionManager specifically checks for active physical connections on reset as of Hibernate 5.
Issue: SPR-13269
Issue: SPR-13002
Xnio 3.4.0 will introduce a new source of ByteBuffers: ByteBufferPool.
Previously this feature was offered by Pooled/Pool/ByteBufferSlicePool;
those classes are now marked as deprecated.
As of 1.3.0.Beta9, Undertow still implements the following method in its
ClientConnection interface, using those deprecated types:
Pool<ByteBuffer> getBufferPool();
This commit prepares compatibility by suppressing warnings in order to
avoid build failures in our build. Once appropriate changes are made in
Undertow, a specific implementation with new types could be introduced.
Issue: SPR-13366
Before this commit UriComponents was capable of expanding URI vars that
may have contained a regular expressions (as supported with
@RequestMapping for example). However if the regular expressions
contained any nested "{}" the expand did not work correctly.
This commit sanitizes a URI template source removing any content
between nested "{}" prior to expanding. This works since we only care
about the URI variable name.
Issue: SPR-13311
Just enough for a test with an @ResponseBody method that accepts an
@RequestParam String arg and returning Publisher<String> or String.
See RequestMappingIntegrationTests.
Prior to this change, VersionResourceResolver and VersionStrategy would
resolve static resources using version strings. They assist
ResourceHttpRequestHandler with serving static resources. The
RequestHandler itself can be configured with HTTP caching strategies to
set Cache-Control headers.
In order to have a complete strategy with Cache-Control and ETag
response headers, developers can't reuse that version string information
and have to rely on other mechanisms (like ShallowEtagHeaderFilter).
This commit makes VersionResourceResolver use that version string to set
it as a request attribute, which will be used by the
ResourceHttpRequestHandler to write an ETag response header.
Issue: SPR-13382
Prior to this change, ResourceUrlEncodingFilter and ResourceUrlProvider
would try to resolve the resource path using the full request URL (i.e.
request path and request parameters), whereas the request path is the
only information to consider.
This would lead to StringIndexOutOfBoundsExceptions when the path +
request params information was given to the AntPathMatcher.
This commit makes the appropriate change to both
ResourceUrlEncodingFilter and ResourceUrlProvider, in order to only
select the request path.
Issue: SPR-13374
This commit introduces the following changes:
- Content type can now be properly configured
- Default content type is "text/html"
- Content type and charset are now properly set in the response
Issue: SPR-13379
This commit adds support for simple URL handler mapping (exact path
match) and an adapter for the HttpHandler interface to be used to
handle the request.
The SimpleUrlHandlerMappingIntegrationTests then maps the URLs
"/foo" and "/bar" to two different handlers.
This is a refactoring of the existing "echo" integration test with the
goal to make it easier to add further integration tests.
The HttpServer abstraction is on the test source side for now.
Introduce http and dispatch packages under org.springframework.web to
separate HTTP-specific adapter code from higher level web framework
code. Move classes into their respective locations.
Prior to this change, trying to set an unquoted ETag with
`ResponseEntity`'s API would throw an `IllegalArgumentException`.
This commit automatically quotes ETag values set using ResponseEntity.
Issue: SPR-13378
In an attempt to make our Jetty-based integration tests more robust,
this commit discontinues use of SocketUtils for picking a random,
available port and instead lets the Jetty Server pick its own port.
The StompSubProtcolHandler now checks the outcome of the send to the
inbound client channel. If the message was prevented from being sent,
e.g. as part of authorization, events are not published
Issue: SPR-13339
Before this commit RequestPartServletServerHttpRequest simply did an
instanceof check for MultipartHttpServletRequest. That hasn't failed
because request wrapping typically happens in filters before the
DispatcherServlet calls the MultipartResolver.
With Spring MVC Test and the Spring Security integraiton however,
this order is reversed since there we prepare the multipart request
upfront, i.e. there is no actual parsing.
The commit unwraps the request if necessary.
Issue: SPR-13317
Prior to this commit, EmbeddedDatabaseFactory logged the name of an
embedded database just before it was created; however, the name alone
is not sufficient for connecting to the database via external tools
such as the H2 Web Console.
This commit updates EmbeddedDatabaseFactory to make it easier to
connect to embedded databases via external tools by logging the
complete connection URL for an embedded database as it's being created.
In addition, EmbeddedDatabaseFactory now logs when an embedded database
is being shut down.
Issue: SPR-13370
Instead of having to use the default constructor then calling
setObjectMapper(ObjectMapper), these constructors allow
MappingJackson2JsonView and MappingJackson2XmlView to be created and
configured with the desired object mapper in one step.
HandlerMapping, HandlerAdapter, HandlerResultHandler (+ HandlerResult)
as the basic request handling contracts. DispatcherHandler to drive
overall request handling.
DispatcherApp provides minimal implementations of the above contracts
enough to put together a running example that returns
200 text/plain "Hello world".
This commit introduces new `isEmpty()` and `isNotEmpty()` methods in
`JsonPathResultMatchers` and `JsonPathRequestMatchers` which delegate
to the new `assertValueIsEmpty()` and `assertValueIsNotEmpty()` methods
in `JsonPathExpectationsHelper`, respectively.
Issue: SPR-13352
Commit fffdd1e9e9 introduced additional
JsonPath result matchers in JsonPathResultMatchers for server-side
testing of MVC controllers.
This commit introduces comparable methods in JsonPathRequestMatchers
for client-side testing with a RestTemplate.
- isString()
- isBoolean()
- isNumber()
- isMap()
Issue: SPR-13320
Prior to this commit, the exists() method in JsonPathExpectationsHelper
correctly asserted that the evaluated JsonPath expression resulted in a
value (i.e., that a non-null value exists); however, if the value was
an empty array, the exists() method always threw an AssertionError.
The existing behavior makes sense if the JsonPath expression is
'indefinite' -- for example, if the expression uses a filter to select
results based on a predicate for which there is no match in the JSON
document, but the existing behavior is illogical and therefore invalid
if the JsonPath expression is 'definite' (i.e., directly references an
array in the JSON document that exists but happens to be empty). For
example, prior to this commit, the following threw an AssertionError.
new JsonPathExpectationsHelper("$.arr").exists("{ 'arr': [] }");
Similar arguments can be made for the doesNotExist() method.
After thorough analysis of the status quo, it has become apparent that
the existing specialized treatment of arrays is a result of the fact
that the JsonPath library always returns an empty list if the path is
an 'indefinite' path that does not evaluate to a specific result.
Consult the discussion on "What is Returned When?" in the JsonPath
documentation for details:
https://github.com/jayway/JsonPath#what-is-returned-when
This commit addresses these issues by ensuring that empty arrays are
considered existent if the JsonPath expression is definite but
nonexistent if the expression is indefinite.
Issue: SPR-13351
Prior to this commit, a JsonPath assertion that a path expression
evaluated to an array in JsonPathExpectationsHelper (and therefore
indirectly in JsonPathResultMatchers in Spring MVC Test) would
incorrectly fail if the array was present in the JSON content but empty.
This commit fixes this issue by removing the "not empty" check for
arrays and lists.
Issue: SPR-13320
SocketUtils is used to find available ports on localhost; however,
prior to this commit, SocketUtils incorrectly reported a port as
available on localhost if another process was already bound to
localhost on the given port but not to other network interfaces. In
other words, SocketUtils determined that a given port was available for
some interface though not necessarily for the loopback interface.
This commit addresses this issue by refactoring SocketUtils so that it
tests the loopback interface to ensure that the port is actually
available for localhost.
Issue: SPR-13321
This commit introduces an additional test case to ensure that explicit
local attribute aliases (configured via @AliasFor) do not accidentally
override attributes of the same names in meta-annotations (i.e., by
convention).
Issue: SPR-13325
This commit adds RxNetty integration that includes RxNetty-based
implementations of ServerHttpRequest and ServerHttpResponse as well as
an adapter from the RxNetty RequestHandler to the HttpHandler contracts.
Only byte[] is supported at the moment for reading and writing with a
corresponding copy to and from Netty ByteBuf.
This commit introduces HTTP request and response abstractions along
with Servlet-based implementations similar to the ones in the http
package of spring-web but using Reactive Streams.
In turn HttpHandler now accepts the request and response types and
returns Publisher<Void> that reflects the end of handling.
The write method on the response also returns Publisher<Void> allowing
deferred writing. At the moment however the underlying Servlet 3.1
support only supports a single publisher after which the connection
is closed.
Only simple byte[] is supported for reading and writing.
Prior to this commit, attempting to synthesize an annotation from a map
of annotation attributes that contained nested maps instead of nested
annotations would result in an exception.
This commit addresses this issue by properly synthesizing nested maps
and nested arrays of maps into nested annotations and nested arrays of
annotations, respectively.
Issue: SPR-13338
It is a configuration error if an alias is declared via @AliasFor for
an attribute in a meta-annotation and the meta-annotation is not
meta-present. However, prior to this commit, the support for validating
the configuration of @AliasFor in AnnotationUtils currently silently
ignored such errors.
This commit fixes this by throwing an AnnotationConfigurationException
whenever a required meta-annotation is not present or meta-present on
an annotation that declares an explicit alias for an attribute in the
meta-annotation.
Issue: SPR-13335
For Tomcat, failures occur if HttpHandlerServlet buffer size is
significantly less than the Tomcat input buffer size.
Also on command line Jetty tests fail with port unavailable unless
the server from the Tomcat tests is also destroyed.
Prior to this commit, MockHttpServletRequestBuilder always supplied an
array of cookies to the MockHttpServletRequest that it built, even if
the array was empty.
However, this violates the contract of HttpServletRequest. According to
the Servlet API, the getCookies() method "returns null if no cookies
were sent."
This commit ensures that MockHttpServletRequestBuilder no longer
configures an empty array of cookies in the mock request that it builds.
Issue: SPR-13314
This commit introduces the following methods in JsonPathResultMatchers
in the Spring MVC Test framework.
- isString()
- isBoolean()
- isNumber()
- isMap()
In addition, this commit overhauls the Javadoc in
JsonPathResultMatchers and JsonPathExpectationsHelper.
Issue: SPR-13320
This commit aims to improve the space and time performance of
NumberUtils by invoking valueOf() factory methods instead of the
corresponding constructors when converting a number to a target class.
Prior to this commit, an explicit override for an attribute in a
meta-annotation configured via @AliasFor could potentially result in an
incorrect override of an attribute of the same name but in the wrong
meta-annotation.
This commit fixes the algorithm in getAliasedAttributeName(Method,
Class) in AnnotationUtils by ensuring that an explicit attribute
override is only applied to the configured target meta-annotation
(i.e., configured via the 'annotation' attribute in @AliasFor).
Issue: SPR-13325
This change ensures that an onError outcome from an async request is
also routed to onCompletion handlers registered with
StandardServletAsyncWebRequest.
Issue: SPR-13292
Prior to this commit, the `ResponseStatusExceptionResolver` would use:
* `HttpServletResponse.sendError` if both a status and a reason are set
on the `@ResponseStatus` annotation
* `HttpServletResponse.setStatus` if only a status is set on the
`@ResponseStatus` annotation
This is actually a change of behavior, since this Resolver was using
`sendError` in all cases previously.
Because this change can create issues such as
https://github.com/spring-projects/spring-boot/issues/3623
this commit rollbacks those changes and clarifies the behavior on the
javadoc of the annotation itself.
Issue: SPR-11193, SPR-13226
SPR-11512 introduced support for annotation attribute aliases via
@AliasFor, requiring the explicit declaration of the 'attribute'
attribute. However, for aliases within an annotation, this explicit
declaration is unnecessary.
This commit improves the readability of alias pairs declared within an
annotation by introducing a 'value' attribute in @AliasFor that is an
alias for the existing 'attribute' attribute. This allows annotations
such as @ContextConfiguration from the spring-test module to declare
aliases as follows.
public @interface ContextConfiguration {
@AliasFor("locations")
String[] value() default {};
@AliasFor("value")
String[] locations() default {};
// ...
}
Issue: SPR-13289
Before this change, XhrTransport implementations had to be configured
with the headers to use for HTTP requests other than the initial
handshake.
After this change the handshake headers passed to SockJsClient by
default are used for all other HTTP requests related to the SockJS
connection (e.g. info request, xhr send/receive). A property on
SockJsClient allows restricting the headers to use for other HTTP
requests to a subset of the handshake headers.
Issue: SPR-13254
This commit fixes numerous references to 'legacy' packages within the
Javadoc for the Spring MVC Test framework.
In addition, this commit improves examples in Javadoc, adds links to
related classes where appropriate, and removes unnecessary imports for
types that are only referenced within documentation.
Issue: SPR-13284
This commit introduces a dedicated build() method in
MockMvcHtmlUnitDriverBuilder to replace createDriver(). In addition,
the configureDriver() method has been renamed to withDelegate() and now
returns the builder for further customization.
This commit also overhauls the Javadoc for static factory methods and
the class-level Javadoc in MockMvcHtmlUnitDriverBuilder for greater
clarity to end users.
Issues SPR-13158
This commit introduces a dedicated build() method in
MockMvcWebClientBuilder to replace createWebClient(). In addition, the
configureWebClient() method has been renamed to withDelegate() and now
returns the builder for further customization.
This commit also overhauls the constructor and class-level Javadoc in
MockMvcWebClientBuilder for greater clarity to end users.
Issues SPR-13158
This commit renames the configureWebClient() method in
WebConnectionHtmlUnitDriver to modifyWebClientInternal() in order to
better convey the relationship to HtmlUnitDriver#modifyWebClient().
Issues SPR-13158
Some of the HtmlUnit Tests required an internet connection. This
caused failures when running offline.
This commit adds Assume PERFORMANCE to those tests so they are
only ran when the PERFORMANCE group is selected.
Issue: SPR-13158
* SPR-13158:
Polish MockMvc HtmlUnit Support
Ensure spring-test builds against HttpComponents 4.5
Upgrade to HtmlUnit 2.18 GA
Mention HtmlUnit support in the What's New section
Introduce support for HtmlUnit in Spring MVC Test
This commit introduces integration between MockMvc and HtmlUnit, thus
simplifying end-to-end testing when using HTML-based views and enabling
developers to do the following.
- Easily test HTML pages using tools such as HtmlUnit, WebDriver, & Geb
without the need to deploy to a Servlet container
- Test JavaScript within pages
- Optionally test using mock services to speed up testing
- Share logic between in-container, end-to-end tests and
out-of-container integration tests
Issue: SPR-13158
Since @TransactionConfiguration is now deprecated, this commit also
deprecates TransactionConfigurationAttributes with the intention of
completely removing TransactionConfigurationAttributes once
@TransactionConfiguration has been removed.
Issue: SPR-13277
Due to common usage of @Rollback(false), this commit introduces a new
@Commit annotation that more clearly conveys the intent of the code
while retaining the run-time semantics.
@Commit is in fact meta-annotated with @Rollback(false).
Issue: SPR-13279
Since Spring Framework 2.5, @Rollback has been supported on test
methods, with class-level rollback settings configured via
@TransactionConfiguration; however, allowing @Rollback to be declared
on test classes with method-level declarations overriding class-level
declarations would prove more intuitive than having to declare both
@TransactionConfiguration and @Rollback. Furthermore, the
transactionManager flag in @TransactionConfiguration was made
superfluous many years ago with the introduction of support for a
qualifier in @Transactional.
This commit enables @Rollback to be declared at the class level for
default rollback semantics within test class hierarchies and deprecates
@TransactionConfiguration in favor of @Rollback and @Transactional
qualifiers.
Issue: SPR-13276, SPR-13277
AbstractMessageConverter provides overloaded methods with a conversion hint, MappingJackson2MessageConverter takes that hint into account, and SimpMessagingTemplate transformes such a hint in the given headers map into an explicit argument invocation argument.
Issue: SPR-13265
Prior to this change, calling the `setDateHeader` method on a
Spring Test MockHttpServletResponse instance would just store the given
long value in a Map, not writing it as a formatted date String.
Also, calling `getDateHeader` on a MockHttpServletRequest would not
support date strings and could not parse those values.
This can be problematic when testing features related to date headers
such as "Expires", "If-Modified-Since", "Last-Modified", etc.
This commit adds formatting and parsing capabilities to Servlet Mocks
for date strings in HTTP headers.
When formatting dates to Strings, the date format used is the one
preferred by the HTTP RFC. When parsing date Strings, multiple date
formats are supported for better compatibility.
Issue: SPR-11912
SPR-13211 introduced support for reusing mock requests in Spring MVC
Test if the request was created by the the Spring TestContext
Framework. Unfortunately, that change makes it impossible for
MockMvc.perform() to be invoked multiple times within the same test
method without side effects. For example, session attributes and
request parameters are transparently and unexpectedly retained for
subsequent invocations of perform(), causing certain categories of
tests to fail.
This commit reverts the changes introduced in SPR-13211 and introduces
a new MockMvcReuseTests class to serve as regression tests within
Spring's test suite.
Issue: SPR-13260, SPR-13211
HTTP headers such as "Expires", "Last-Modified" all use date
strings like "Tue, 21 Jul 2015 10:00:00 GMT". Prior to this commit,
there was no way to match those header values, besides formatting dates
manually.
This commit introduces a new HeaderResultMatcher to test those date
headers using a long timestamp:
```
this.mockMvc.perform(get("/persons/1").header("If-Modified-Since", now))
.andExpect(status().isNotModified())
.andExpect(header().dateValue("Last-Modified", timestamp));
```
Issue: SPR-13263
Prior to this change, calling the `setDateHeader` method on a
MockHttpServletResponse instance (internal implementation for testing
the spring-web module) would just store the given long value in a Map,
not writing it as a formatted date String.
This can be problematic when testing features related to date headers
such as "Expires", "If-Modified-Since", "Last-Modified", etc.
This commit formats long dates into date Strings using the date format
recommended by the RFC and the GMT time zone.
As filter-based libraries and projects (such as Spring Security) may
use the "Pragma" header in HTTP responses, WebContentGenerator should
make sure that such headers are overwritten to avoid clashes with
the HTTP caching headers set by the HTTP caching configuration.
Issue: SPR-13252
Prior to this commit, the Spring MVC Test Framework always created a
new MockHttpServletRequest, disregarding any mock request already
present in Spring Web's RequestContextHolder -- for example, one
created by the ServletTestExecutionListener in the Spring TestContext
Framework (TCF).
This commit modifies MockHttpServletRequestBuilder so that it reuses a
mock request created by the TCF. However,
MockMultipartHttpServletRequestBuilder continues to always create a new
MockMultipartHttpServletRequest since a MockHttpServletRequest created
by the TCF is not directly compatible with a
MockMultipartHttpServletRequest. Furthermore, in order to avoid
unforeseen side effects, MockHttpServletRequestBuilder will always
create a new MockHttpServletRequest if a mock request is present in the
RequestContextHolder but not created by the TCF.
Issue: SPR-13211
When resolving resources, the PathResourceResolver creates a Resource
instance and checks whether this resource `exists()` and `isReadable()`.
While that last call returns false for folders on the file system, both
calls return true for folders located inside JARs.
If a JAR location is configured as a resource location, then
PathResourceResolver can resolve folders in JARs as valid locations and
candidates for paths resolution.
Prior to this change, the PathResourceResolver would resolve "" as a
valid resource path (here, the "/META-INF/resources/webjars" if
configured, for example) and return a "" path for this resource,
effectively turning all "/" URLs into empty ones "".
This commit fixes the resolveUrlPathInternal implementation by not
allowing empty paths as valid resource paths.
Issue: SPR-13241
This commit adds a new sharedEngine property to ScriptTemplateConfigurer
and ScriptTemplateView in order to support non thread-safe ScriptEngine
implementations like Nashorn.
When this flag is set to false, the engine is retrieved from a
ThreadLocal<ScriptEngine> field instead of a ScriptEngine one.
Also as part of this commit, all the initialization logic has been moved from
ScriptTemplateConfigurer to ScriptTemplateView since the script engine can
now be lazily initialized multiple time in the view when sharedEngine is
set to false.
Issue: SPR-13034
Some databases such as Oracle permit double quoted column aliases that
contain case-sensitive characters, single quotes, and other special
characters; however, prior to this commit, SqlScripts interpreted a
single quote nested within double quotes as the start of a string
literal resulting in improper parsing.
This commit addresses this issue by ensuring that double quoted strings
such as column aliases are properly parsed even when containing single
quotes.
Issue: SPR-13218
When using an Apache Http components based infrastructure, a null header
value is handled as the empty string. The exact same infrastructure using
HttpURLConnection generates a header with no colon. This is actually not
proper HTTP and some components fail to read such request.
We now make sure to call HttpURLConnection#addRequestProperty with the
empty String for a null header value.
Issue: SPR-13225
Browsers like Chrome or Safari include an Origin header for same-origin
POST/PUT/DELETE requests, not only for cross-origin requests.
Before this commit, these same-origin requests would have been detected
as potential cross-origin requests, and rejected if the same-origin domain
is not part of the configured allowedOrigins.
This commit avoid to reject same-origin requests by reusing the logic
introduced in Spring 4.1 for detecting reliably Websocket/SockJS
same-origin requests with the WebUtils.isValidOrigin() method. This
logic has been extracted in a new WebUtils.isSameOrigin() method.
Issue: SPR-13206
When using the Spring TestContext Framework (TCF) to load a
WebApplicationContext and the Spring MVC Test Framework (MockMvc) to
test a controller, two instances of MockHttpServletRequest will be
created. Due to an ordering issue with regard to population of the
RequestAttributes, it is therefore possible that a filter accesses the
mocked request managed by the TCF, while the controller accesses the
mocked request managed by MockMvc, and this leads to test failures if
the controller expects data from the filter to be present in the
request.
This commit fixes this bug by ensuring that the RequestAttributes
backed by the mocked request managed by MockMvc are stored in the
RequestContextHolder before any filters are invoked by MockMvc.
Issue: SPR-13217
This commit introduces the following changes:
- The new CorsConfigurationMapping class allows to share the mapped
CorsConfiguration logic between AbstractHandlerMapping and CorsFilter
- In AbstractHandlerMapping, the Map<String, CorsConfiguration>
corsConfiguration property has been renamed to corsConfigurations
- CorsFilter allows to process CORS requests at filter level, using any
CorsConfigurationSource implementation (for example
CorsConfigurationMapping)
Issue: SPR-13192
By default, RedirectViews have http10Compatible set to true, which means
that they use HTTP 302 as a default HTTP response status. Setting this
property to false make RedirectViews use HTTP 303 by default.
Now when set to false, RedirectViews also don't use the
RESPONSE_STATUS_ATTRIBUTE request attribute as a response HTTP if it is
available.
This commit makes both configuration choices behave the same regarding
this request attribute: use it as a response status if it's available.
Issue: SPR-13208
In addition to specifying the event type to listen to via a method
parameter, any @EventListener annotated method can now alternatively
define the event type(s) to listen to via the "classes" attributes (that
is aliased to "value").
Something like
@EventListener({FooEvent.class, BarEvent.class})
public void handleFooBar() { .... }
Issue: SPR-13156
As of SPR-11792, WebContentGenerator and WebContentInterceptor offer
new APIs and new behavior regarding HTTP caching, including the use of a
new CacheControl class.
Those changes broke part of the behavior in WebContentInterceptor. This
class allows to override the global Cache configuration at the Generator
level, using specific mappings. Prior to this change, those mappings
would not properly apply the HTTP caching configuration when using
deprecated configuration settings in WebContentGenerator.
This change fixes those backwards compatibility issues for
WebContentInterceptor users.
Issue: SPR-13207
This commit adds additional tests to RequestContextHolderTests that
verify proper support for the MockHttpServletRequest managed by Spring
MVC Test in the following scenarios:
- request-scoped service invoked by controller
- session-scoped service invoked by controller
- custom filter that sets request attributes
Issue: SPR-13211
Conversion and validation documentation related to Spring MVC is now
consolidated in the Spring MVC chapter with references to and from
the Validation and Data Binding chapter.
Examples have been updated to include MVC Java config as well.
When using Appache Commons FileUpload, multi parts with binary data
(i.e. that are not actual files) are saved and then accessed as
String request parameters.
Before this change however the RequestPartServletServerHttpRequest
used a fixed encoding (UTF-8) while the parsing code in
CommonsFileUploadSupport/Resolver used the encoding from the
content-type header, or the request, or the FileUpload component.
This change does a best effort to determine the encoding of the
request parameter using a similar algorithm as the parsing side
that should work the same unless the encoding comes from the
FileUpload component which is not accessible.
Issue: SPR-13096
Add section on Spring MVC TEst vs full integation testing and provide
reference to Spring Boot's @WebIntegrationTest as an alternative.
Issue: SPR-13169
After SPR-12884 (4.2 RC1) introduced support for a selector header
expression on SUBSCRIBE frames, messages from the destination cache
are further filtered based on the selector expression. While adding a
test to find subscriptions at the same time as unsubscribing, a
potential NPE was exposed. This commit fixes the NPE.
Issue: SPR-13204
Before this change <websocket:decorator-factory> decorated to
the SubProtocolWebSocketHandler RootBeanDefinition rather than
using a RuntimeBeanReference, which led to a separate instance
of SubProtocolWebSocketHandler to be created.
Issue: SPR-13190
SPR-12429 introduced various `BEFORE_*` modes in `@DirtiesContext`. To
support these new modes, `DirtiesContextTestExecutionListener` (DCTEL)
was updated to support both `BEFORE_*` and `AFTER_*` modes. However,
there is a problem with having DCTEL support `BEFORE_*` modes since it
is typically configured to execute after the
`DependencyInjectionTestExecutionListener` (DITEL), and this leads to
several undesired side effects:
- The test's `ApplicationContext` is closed by DCTEL *after*
dependencies have been injected into the test instance.
- Injected dependencies may therefore attempt to interact with an
`ApplicationContext` that is no longer _active_.
- If a test has its `ApplicationContext` injected as a dependency,
interaction with the context will likely fail since the context has
been closed.
- Any `TestExecutionListeners` registered after DCTEL will get a _new_
`ApplicationContext` if they invoke `getApplicationContext()` on the
`TestContext`.
This commit fixes these issues by introducing a new
`DirtiesContextBeforeModesTestExecutionListener` (DCBMTEL) that is
registered by default before DITEL. The previous support for `BEFORE_*`
modes has been moved from DCTEL to DCBMTEL. In addition, an
`AbstractDirtiesContextTestExecutionListener` has been extracted from
DCTEL in order to avoid code duplication.
Issue: SPR-13180
This commit moves the check whether an HTTP method supports request
body up to the base class so that all sub-classes can benefit (not just
@RequestBody).
Issue: SPR-13176
Since the changes introduced in SPR-12778, some `@RequestBody` args
would not be properly processed in some cases:
* requests with an empty body
* no Content-Type header defined
This typically happens when GET requests are mapped on a handler dealing
with POST requests and HTTP bodies.
This change makes sure that the `RequestResponseBodyMethodProcessor` is
only involved for requests that:
* have a Content-Type defined
* OR are HTTP requests eligible for an HTTP body (PUT, POST, PATCH)
Issue: SPR-13176
Fixesspring-projects/spring-boot#3313
Beginning with Java 6, the JavaBeans Activation Framework (JAF) is part
of the JDK. Thus, there is no longer a need to explicitly include a
dependency on `activation.jar` when using Spring's email support in
Spring Framework 4.0 and higher which anyway requires Java 6 or higher.
This commit therefore removes the JAF requirement from the reference
manual.
This split avoids a package tangle (between core and core.annotation) and also allows for selective use of raw annotation exposure versus synthesized annotations, with the latter primarily applicable to web and message handler processing at this point.
Issue: SPR-13153
Prior to this commit, `HttpEntityMethodProcessor` would rely on
`ServletWebRequest` to process conditional requests and with incoming
`"If-Modified-Since"` / `"If-None-Match"` request headers.
This approach is problematic since in that class:
* response is wrapped in a `ServletServerHttpResponse`
* this wrapped response does not write response headers right away
* `ServletWebRequest.checkNotModified` methods can't apply their
logic with incomplete response headers
This solution adds some minimal code duplication and applies
the conditional request logic within the Processor.
A possible alternative would be to improve the
`ServletServerHttpResponse$ServletResponseHttpHeaders` implementation
with write methods - but this solution would only work for Servlet 3.x
applications.
Issue: SPR-13090
Prior to this commit, the Spring MVC Test framework only provided
support for printing debug information about the MvcResult to STDOUT.
This commit introduces support for logging `MvcResult` details at
`DEBUG` level via the Apache Commons Logging API. In addition, this
commit introduces additional `print(..)` variants for printing debug
information to custom output streams and writers.
Specifically, `MockMvcResultHandlers` has been augmented with the
following new static methods:
- `log()`
- `print(OutputStream)`
- `print(Writer)`
Issue: SPR-13171
Prior to this commit, when rendering cookies via `andDo(print())` in
Spring MVC Test, the output for the `MockHttpServletResponse` would
look something like the following:
Cookies = [javax.servlet.http.Cookie@25084a1e]
The reason is that the Cookie class in javax.servlet-api-3.0.1.jar does
not implement toString(). Consequently, nothing about the cookie's
name, value, etc., is displayed, thereby making the debug output for
cookies next to useless.
This commit improves on this by implementing custom toString() logic
for cookies in debug output in Spring MVC Test. For example, the output
now looks like this (without the newlines):
Cookies = [[Cookie@47faa49c name = 'enigma', value = '42', \\
comment = [null], domain = [null], maxAge = -1, \\
path = [null], secure = false, version = 0, \\
httpOnly = false]]
In addition, this commit fixes a minor bug for FlashMap debug output if
the FlashMap is empty.
Issue: SPR-13168
Add a section on Groovy Markup Template support and
reorder sections in the View Technologies chapter, to have in order:
* Thymeleaf
* Groovy Markup Template
* Velocity and Freemarker
* JSPs
* Script Templates
* other views...
Issue: SPR-12829
This commit introduces the following changes:
- In AbstractMessageConverterMethodProcessor, the type aware variant of
canWrite() is now called when the converter implements
GenericHttpMessageConverter.
- The Javadoc has been updated in GenericHttpMessageConverter to make it clear
that the type aware canRead() and canWrite() methods should perform the same
checks than non type aware ones.
- AbstractGenericHttpMessageConverter now implements default type aware
canRead() and canWrite() methods than just call the non type aware variants.
Due to this, if subclasses just override the non type aware variants,
they still have the right behavior.
Issue: SPR-13161
Recent builds of Jetty 9.3 require that Jetty's own ServletContext
implementation be supplied to WebSocketServerFactory's init() method.
Otherwise, the Jetty server will fail to start with the exception
message: "Not running on Jetty, WebSocket support unavailable".
This commit refactors AbstractWebSocketIntegrationTests,
AbstractSockJsIntegrationTests, and all WebSocketTestServer
implementations in order to support this new requirement.
Specifically:
- WebSocketTestServer defines a new getServletContext() method;
TomcatWebSocketTestServer, UndertowTestServer, and
JettyWebSocketTestServer have all been updated to return the
ServletContext created by the embedded server.
- The setup() methods in AbstractWebSocketIntegrationTests and
AbstractSockJsIntegrationTests have been updated so that the
WebApplicationContext is supplied the appropriate ServletContext,
after deployConfig() has been invoked on the WebSocketTestServer but
before the WebApplicationContext is refreshed.
Issue: SPR-13162
The JettySockJsIntegrationTests are enabled in the performance build
only. Following the upgrade to Jetty 9.3 where the
JettyRequestUpgradeStrategy is now Lifecycle as wel as
ServletContextAware, we need to make sure the ApplicationContext
refresh occurs after the ServletContext has been set. This change
removes the explicit .refresh() call in the test setup and instead
relies on the DispatcherServlet to do that, which ensures that the
ServletContext with which it is initialized by Jetty has been set
on the ApplicationContext before that.
Prior to this commit, Spring's MimeType checked for equality between
two MIME types based on the equality of their properties maps; however,
the properties maps contain string representations of the "charset"
values. Thus, "UTF-8" is never equal to "utf-8" which breaks the
contract for character set names which must be compared in a
case-insensitive manner.
This commit addresses this issue by ensuring that "charset" properties
in MimeType instances are compared as Java Charset instances, thereby
ignoring case when checking for equality between charset names.
Issue: SPR-13157
Prior to this commit, it was only possible to declare SQL statements
via @Sql within external script resources (i.e., classpath or file
system resources); however, many developers have inquired about the
ability to inline SQL statements with @Sql analogous to the support for
inlined properties in @TestPropertySource.
This commit introduces support for declaring _inlined SQL statements_
in `@Sql` via a new `statements` attribute. Inlined statements are
executed after statements in scripts.
Issue: SPR-13159
After this change JettyRequestUpgradeStrategy implements Lifecyle,
which is used to init and cleanup the Jetty WebSocketServerFactory.
Since a RequestUpgradeStrategy is typically created reflectively
within DefaultHandshakeHandler, the Lifecycle events are propagated
from the top, i.e. the Spring MVC HandlerMapping through the
WebSocket/SockJsHttpRequestHandler.
Issue: SPR-13140
This commit adds canWrite() and write() methods to the
GenericHttpMessageConverter interface. These are type aware variants
of the methods available in HttpMessageConverter, in order to keep
parametrized type information when serializing objects.
AbstractMessageConverterMethodProcessor now calls those type aware
methods when the message converter implements GenericHttpMessageConverter.
AbstractJackson2HttpMessageConverter and GsonHttpMessageConverter uses
these new methods to make @ResponseBody method return type available
for type resolution instead of just letting the JSON serializer trying
to guess the type to use from the object to serialize.
Issue: SPR-12811
Previously, a method could only declare one Jms endpoint so if several
destinations share the exact same business logic, you'd still need one
separate method declaration per destination.
We now make sure that JmsListener is a repeatable annotation, introducing
JmsListeners for pre Java8 use cases.
Issue: SPR-13147
This change fixes a NullPointerException in GzipResourceResolver, which
assumed that calls to the `resolveResource` method were made with only
non-null values for request.
This is not the case for the VersionResourceResolver, which tries to
resolve resources that aren't requested per se by the HTTP request.
Issue: SPR-13149
This commit introduces a convenience method in AnnotationUtils for
synthesizing an annotation from its default attribute values.
TransactionalTestExecutionListener has been refactored to invoke this
new convenience method.
Issue: SPR-13087
This commit introduces support for automatically resolving a container
annotation configured via @Repeatable in AnnotationUtils'
getRepeatableAnnotations() and getDeclaredRepeatableAnnotations()
methods.
Issue: SPR-13068
This commit introduces a minor bug fix for getRepeatableAnnotations()
so that it fully complies with the contract of Java's
getAnnotationsByType() method with regard to repeatable annotations
declared on multiple superclasses.
Issue: SPR-13068
- Simplified "check" algorithms in CorsConfiguration
- Improved robustness of setter methods in CorsConfiguration in order to
avoid attempts to modify immutable lists
- Improved CORS documentation and fixed typo
- Introduced constants in CorsConfiguration
- Removed auto-boxing in CorsRegistration
Prior to this commit, the implementation of getRepeatableAnnotation()
in Spring's AnnotationUtils complied neither with the contract of
getAnnotationsByType() nor with the contract of
getDeclaredAnnotationsByType() as defined in AnnotatedElement in Java 8.
Specifically, unexpected results can be encountered when using Spring's
support for @Repeatable annotations: either annotations show up in the
returned set in the wrong order, or annotations are returned in the set
that should not even be found based on the semantics of @Repeatable.
This commit remedies this problem by deprecating the existing
getRepeatableAnnotation() methods and replacing them with new
getRepeatableAnnotations() and getDeclaredRepeatableAnnotations()
methods that comply with the contracts of Java's getAnnotationsByType()
and getDeclaredAnnotationsByType(), respectively.
Issue: SPR-13068
The initial support for synthesizing an annotation from a Map (or
AnnotationAttributes) introduced in SPR-13067 required that the map
contain key-value pairs for every attribute defined by the supplied
annotationType. However, there are use cases that would benefit from
being able to supply a reduced set of attributes and still have the
annotation synthesized properly.
This commit refines the validation mechanism in
MapAnnotationAttributeExtractor so that a reduced set of attributes may
be supplied. Specifically, if an attribute is missing in the supplied
map the attribute will be set either to value of its alias (if an alias
value configured via @AliasFor exists) or to the value of the
attribute's default value (if defined), and otherwise an exception will
be thrown.
Furthermore, TransactionalTestExecutionListener has been refactored to
take advantage of this new feature by synthesizing an instance of
@TransactionConfiguration solely from the default values of its
declared attributes.
Issue: SPR-13087
Before this change ResponseStatusExceptionResolver always used
.sendError despite the javadoc on @ResponseStatus#code. This was
perhaps justifiable from a HandlerExceptionResolver. Nevertheless
.setStatus should be more REST API friendly while still marking
the response as an error.
Issue: SPR-11193
Before this change the AbstractMessageConverterMethodProcessor always
raised a 406 if it couldn't find a converter. However if the reason
for not finding it is because there is simply no converter for the
return value type (i.e. programming error) and doesn't have anything to
do with content negotiation, then we should raise a 500 instead and
make it easier to figure out what's wrong.
Issue: SPR-13135
Prior to this change, `XpathResultMatchers` and more generally the
`MockHttpServletResponse` would default to ISO-8859-1 encoding even when
it's not supposed to. The Servlet/HTTP specs mention this encoding
for all `text/*` mime types when decoding bodies to Strings, but this
issue is about XML Parsers.
XML Parsers should use the encoding:
* defined in the `Content-Type` response header (if available)
* written in the XML declaration of the document
* "guessed" by a built-in auto-detection mechanism
This commit changes the following:
* XPathMatchers now feed the XML parser with byte arrays instead of
decoded Strings
* the response should be written to `MockHttpServletResponse` using
its OutputStream, and not a PrintWriter which defaults to ISO-8859-1
Issue: SPR-12676
This commit improves SPR-13090 and avoids adding duplicate ETag and
Last-Modified headers in HTTP responses.
Previously, those were added twice to the response since:
* we're adding all ResponseEntity headers to the response
* the `checkNotModified` methods automatically add those headers
Issue: SPR-13090
Add JmsResponse that can be used as return type of any JMS listener
method to indicate not only the response but also the actual destination
to which the reply should be sent.
Issue: SPR-13133
Before this change HandlerMethodReturnValueHandler's were invoked in a
specific order (type-based, annotation-based, custom). However handlers
that deal with asynchronous return value handling need to always be
considered first. This affects custom handlers in particular since they
are normally ordered last.
This change introduces an AsyncHandlerMethodReturnValueHandler
sub-interface with a single method to determine if the return value is
asynchronous and if it is to look for a matching handler only among
those that are of type AsyncHandlerMethodReturnValueHandler.
Issue: SPR-13083
This commit introduces the following changes in AbstractHandlerExceptionResolver:
- warnLogger used to log exception is enabled by default
- the exception message is now logged instead of the whole exception stacktrace
- warn logging is only performed if doResolveException() returns a non-null
ModelAndView, in order to avoid logging multiple times the error
Issue: SPR-13100
Before this change a missing path variable value resulted in a 400
error where in fact the error is due to a mismatch between the
declared @PathVariable and the URI template, i.e. a 500 error.
This change introduced a MissingPathVariableException as a sub-class
of ServletRequestBindingException (the exception previously thrown)
and results in a response status code of 500 by default.
Issue: SPR-13121
Ever since @ActiveProfiles was introduced, the declared active profiles
for integration tests have been sorted in order to support unique cache
key generation; however, there are use cases for which the original
ordering should be retained.
For example, Spring Boot's ConfigFileApplicationListener loads
configuration files for active profiles in the order returned by
Environment.getActiveProfiles(), with the assumption that the ordering
matches the order in which the developer declared the active profiles.
This commit maintains the uniqueness of active profiles declared via
@ActiveProfiles but no longer sorts them.
Issue: SPR-12492
In AnnotatedElementUtils, all methods pertaining to merging annotation
attributes have been renamed to "getMerged*()" and "findMerged*()"
accordingly. Existing methods such as getAnnotationAttributes(..) have
been deprecated in favor of the more descriptive "merged" variants.
This aligns the naming conventions in AnnotatedElementUtils with those
already present in AnnotationReadingVisitorUtils.
The use of "annotationType" as a variable name for the fully qualified
class name of an annotation type has been replaced with
"annotationName" in order to improve the readability and intent of the
code base.
In MetaAnnotationUtils.AnnotationDescriptor, getMergedAnnotation() has
been renamed to synthesizeAnnotation(), and the method is now
overridden in UntypedAnnotationDescriptor to always throw an
UnsupportedOperationException in order to avoid potential run-time
ClassCastExceptions.
Issue: SPR-11511
Prior to this commit, there existed several isEmpty() methods scattered
across various utilities such as ObjectUtils, CollectionUtils, and
StringUtils; however, each of these methods requires a cast to the type
supported for that particular variant.
This commit introduces a general-purpose isEmpty(Object) method in
ObjectUtils that transparently supports multiple object types in a
central location without the need for casts or juggling multiple
utility classes.
Issue: SPR-13119
The modifications to DefaultMockMvcBuilder performed in conjunction
with SPR-12553 introduced a breaking change: the WebApplicationContext
supplied to DefaultMockMvcBuilder's constructor was *always* stored in
the ServletContext as the root WebApplicationContext, overwriting a
root WebApplicationContext that had been set by the user or by the
Spring TestContext Framework (TCF) -- for example, in
AbstractGenericWebContextLoader. Consequently, the changes in SPR-12553
cause tests that use @ContextHierarchy to fail if web components rely
on the correct WebApplicationContext being stored under the
WebApplicationContext#ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE key.
This commit reverts the breaking changes introduced in SPR-12553: if
the root WebApplicationContext has already been set in the
ServletContext of the WebApplicationContext supplied to
DefaultMockMvcBuilder, no action is taken.
Furthermore, this commit introduces new code to address the initial
intent of SPR-12553. Specifically, if the root WebApplicationContext
has NOT been set in the ServletContext of the WebApplicationContext
supplied to DefaultMockMvcBuilder, the application context hierarchy
will be traversed in search of the root WebApplicationContext, and the
root WebApplicationContext will then be stored under the
ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE key.
Issue: SPR-13075, SPR-12553
Prior to this change, the `"Last-Modified"` and "`Etag`" support had
been improved with SPR-11324: HTTP response headers are now
automatically added for conditional requests and more.
This commit fixes the format of the "`Last-Modified`" and "`ETag`"
values, which were using an epoch timestamp rather than an HTTP-date
format defined in RFC 7231 section 7.1.1.1.
Also, Conditional responses are only applied when the given response
applies, i.e. when it has an compatible HTTP status (2xx).
Issue: SPR-13090
This commit introduces support for RFC 7239: Forwarded HTTP Extension in
the UriComponentsBuilder. Unfortunately, RFC 7239 is not a complete
replacement for the X-Forwarded-* headers: specifically, there is not
direct replacement for X-Forwarded-Port. The JIRA contains more
information.
Issue: SPR-11856
Provide a mean to detect the actual ResolvableType based on a instance as
a counter measure to type erasure.
Upgrade the event infrastructure to detect if the event (or the payload)
implements such interface. When this is the case, the return value of
`getResolvableType` is used to validate its generic type against the
method signature of the listener.
Issue: SPR-13069
This commit introduces the following changes:
- configureCors(CorsConfigurer configurer) is renamed to
addCorsMappings(CorsRegistry registry)
- enableCors(String... pathPatterns) is renamed to
addMapping(String pathPattern)
- <cors /> element must have at least one <mapping /> child
element in order to be consistent with XML based configuration
and have more explicit configuration
Issues: SPR-12933, SPR-13046
While working on SPR-12532, an extra IdentityWrapper was added to work
around a backward compatible issue between commons pool 1.x and 2.x. This
issue (POOL-283) has actually been fixed in 2.4 and their IdentityWrapper
is using object equality so our wrapper is in the way.
Looking retrospectively, the code looks all fine without the workaround
and commons pool 2.4 or later so it has been removed.
Since Spring 4.1, a CacheResolver may be configured to customize the way
the cache(s) to use for a given cache operation are retrieved. Since a
CacheResolver implementation may not use the cache names information at
all, this attribute has been made optional.
However, a fix was still applied, preventing a Cache operation without a
cache name to be defined properly. We now allow this valid use case.
Issue: SPR-13081
This commit introduces support for this kind of CORS XML namespace configuration:
<mvc:cors>
<mvc:mapping path="/api/**"
allowed-origins="http://domain1.com, http://domain2.com"
allowed-methods="GET, PUT"
allowed-headers="header1, header2, header3"
exposed-headers="header1, header2" allow-credentials="false"
max-age="123" />
<mvc:mapping path="/resources/**" allowed-origins="http://domain1.com" />
</mvc:cors>
Issue: SPR-13046
This commit introduces new 'cacheNames' attributes (analogous to the
existing attribute of the same name in @CacheConfig) as aliases for the
'value' attributes in @Cacheable, @CachePut, and @CacheEvict.
In addition, SpringCacheAnnotationParser.getAnnotations() has been
refactored to support synthesized annotations.
Issue: SPR-11393
Prior to this commit, @ComponentScan already had a value/basePackages
alias pair; however, the semantics were not properly enforced.
This commit addresses this issue by refactoring
ComponentScanAnnotationParser to ensure that it is not possible to
declare both of the aliased attributes. In addition, the 'value' and
'basePackages' attributes are now annotated with @AliasFor in order to
make the semantics clearer.
Issue: SPR-11393
This commit introduces a "synthesized annotation" alternative to
getAnnotationAttributes() in AnnotatedElementUtils, analogous to the
recently introduced findAnnotation() methods.
Issue: SPR-13082
Spring Framework 4.2 RC1 introduced support for synthesizing an
annotation from an existing annotation in order to provide additional
functionality above and beyond that provided by Java. Specifically,
such synthesized annotations provide support for @AliasFor semantics.
As luck would have it, the same principle can be used to synthesize an
annotation from any map of attributes, and in particular, from an
instance of AnnotationAttributes.
The following highlight the major changes in this commit toward
achieving this goal.
- Introduced AnnotationAttributeExtractor abstraction and refactored
SynthesizedAnnotationInvocationHandler to delegate to an
AnnotationAttributeExtractor.
- Extracted code from SynthesizedAnnotationInvocationHandler into new
AbstractAliasAwareAnnotationAttributeExtractor and
DefaultAnnotationAttributeExtractor implementation classes.
- Introduced MapAnnotationAttributeExtractor for synthesizing an
annotation that is backed by a map or AnnotationAttributes instance.
- Introduced a variant of synthesizeAnnotation() in AnnotationUtils
that accepts a map.
- Introduced findAnnotation(*) methods in AnnotatedElementUtils that
synthesize merged AnnotationAttributes back into an annotation of the
target type.
The following classes have been refactored to use the new support for
synthesizing AnnotationAttributes back into an annotation.
- ApplicationListenerMethodAdapter
- TestAnnotationUtils
- AbstractTestContextBootstrapper
- ActiveProfilesUtils
- ContextLoaderUtils
- DefaultActiveProfilesResolver
- DirtiesContextTestExecutionListener
- TestPropertySourceAttributes
- TestPropertySourceUtils
- TransactionalTestExecutionListener
- MetaAnnotationUtils
- MvcUriComponentsBuilder
- RequestMappingHandlerMapping
In addition, this commit also includes changes to ensure that arrays
returned by synthesized annotations are properly cloned first.
Issue: SPR-13067
Prior to this commit, when a nested array of annotations was
synthesized while adapting values within an AnnotationAttributes map,
the array was improperly replaced with an array of type Annotation[]
instead of an array of the concrete annotation type, which can lead to
unexpected run-time exceptions.
This commit fixes this bug by replacing annotations in the existing
array with synthesized versions of those annotations, thereby retaining
the original array's component type.
Issue: SPR-13077
This commit introduces support in AnnotationAttributes for retrieving
nested annotations that is on par with the existing type-safe support
for retrieving nested AnnotationAttributes.
Issue: SPR-13074
AnnotationAttributes has existed for several years, but none of the
"get" methods that make up its public API are documented. In many
cases, the behavior can be inferred from the name of the method, but
for some methods there are "hidden gems" and unexpected behavior
lurking behind the scenes.
This commit addresses this issue by documenting all public methods. In
addition, the hidden support for converting single elements into
single-element arrays has also been documented and tested.
Issue: SPR-13072
Reinstate a variant of the `WebContentGenerator.checkAndPrepare` method
for projects that are using it.
This variant is now marked as deprecated.
Issue: SPR-11792
Before this commit the object that #this would refer to in
nested expressions within projection/selection clauses was always
the root context object. This was incorrect as it should be the
element being projected/selected over. This commit introduces
a scope root context object which is set upon entering a new
scope (like when entering a projection or selection). Any
object. With this change this kind of expression now behaves:
where #this is the element of list1. Unqualified references
are also resolved against this scope root context object.
Issues: SPR-10417, SPR-12035, SPR-13055
This commit introduces a test that will fail if SynthesizedAnnotation is
not public as is required by the contract for getProxyClass() in
java.lang.reflect.Proxy.
Issue: SPR-13057
This commit introduces support for asynchronous return values thanks
to the new AsyncHandlerMethodReturnValueHandler interface. Out of
the box support for ListenableFuture is also provided.
Issue: SPR-12168
Commit 3d86f15 added a lot of new feature in AbstractPropertyAccessor
shared by both DirectFieldAccessor and BeanWrapperImpl. This makes this
abstract class harder to implement for others having simpler use cases.
It turns that Spring Data has such use case; this commit split these new
features in a dedicated new base class, leaving AbstractPropertyAccessor
untouched.
Issue: SPR-12805
Enable public visibility on SynthetizedAnnotation to allow annotation
outside its package to be proxied properly. This commit is pending a
unit test that actually reproduces the problem.
Issue: SPR-13057
This commit introduces first-class support for aliases for annotation
attributes. Specifically, this commit introduces a new @AliasFor
annotation that can be used to declare a pair of aliased attributes
within a single annotation or an alias from an attribute in a custom
composed annotation to an attribute in a meta-annotation.
To support @AliasFor within annotation instances, AnnotationUtils has
been overhauled to "synthesize" any annotations returned by "get" and
"find" searches. A SynthesizedAnnotation is an annotation that is
wrapped in a JDK dynamic proxy which provides run-time support for
@AliasFor semantics. SynthesizedAnnotationInvocationHandler is the
actual handler behind the proxy.
In addition, the contract for @AliasFor is fully validated, and an
AnnotationConfigurationException is thrown in case invalid
configuration is detected.
For example, @ContextConfiguration from the spring-test module is now
declared as follows:
public @interface ContextConfiguration {
@AliasFor(attribute = "locations")
String[] value() default {};
@AliasFor(attribute = "value")
String[] locations() default {};
// ...
}
The following annotations and their related support classes have been
modified to use @AliasFor.
- @ManagedResource
- @ContextConfiguration
- @ActiveProfiles
- @TestExecutionListeners
- @TestPropertySource
- @Sql
- @ControllerAdvice
- @RequestMapping
Similarly, support for AnnotationAttributes has been reworked to
support @AliasFor as well. This allows for fine-grained control over
exactly which attributes are overridden within an annotation hierarchy.
In fact, it is now possible to declare an alias for the 'value'
attribute of a meta-annotation.
For example, given the revised declaration of @ContextConfiguration
above, one can now develop a composed annotation with a custom
attribute override as follows.
@ContextConfiguration
public @interface MyTestConfig {
@AliasFor(
annotation = ContextConfiguration.class,
attribute = "locations"
)
String[] xmlFiles();
// ...
}
Consequently, the following are functionally equivalent.
- @MyTestConfig(xmlFiles = "test.xml")
- @ContextConfiguration("test.xml")
- @ContextConfiguration(locations = "test.xml").
Issue: SPR-11512, SPR-11513
Previously, the binding may have to call the getter first to retrieve the
old value of a property before actually setting it. This was guarded by
a catch block that was accidentally removed in 3d86f15
Restore that catch block and add a test to cover it.
Issue: SPR-12805
Prior to this commit, the `ResourceHttpRequestHandler` would not
properly handle HTTP requests to **directories contained in JARs**.
This would result in HTTP 500 errors, caused by `FileNotFoundException`
or `NullPointerException`.
This can be tracked to webapp ClassLoader implementations in servlet
containers:
* in Jetty9x, fetching a directory within a JAR as a `Resource` and
getting its InputStream work fine, but attempting to `close()` it
results in a NullPointerException as the underlying stream is null.
* In Tomcat6x, one cannot fetch an InputStream for the same `Resource`
as it throws a FileNotFoundException.
This change adds more try/catch clauses and catches more Exception so as
to result in HTTP 200 OK responses instead of server errors. While this
is inconsistent because the same code path would result in HTTP 404 with
existing directories on the file system, there's no other simple way to
make those checks for resources contained in JARs.
Issue: SPR-12999
`BeanWrapperImpl` and `DirectFieldAccessor` are two
`ConfigurablePropertyAccessor` implementations with different features
set.
This commit harmonizes the two implementations to use a common base class
that delegates the actual property handling to the sub-classes:
* `BeanWrapperImpl`: `PropertyDescriptor` and introspection utilities
* `DirectFieldAccessor`: reflection on `java.lang.Field`
Issues: SPR-12206 - SPR-12805
Previously, a Bean implementing `AutoCloseable` (or `Closeable`) was
always destroyed regardless of its bean definition. In particular, the
documented way of disabling the destruction callback via an empty String
did not work.
AutoCloseable beans are now treated pretty much as any other bean: we
still use the presence of the interface to optimize the check of a
destroy method and we only auto-discover the method name to invoke if
the inferred mode is enabled.
Issue: SPR-13022
Prior to this commit, WebJars users needed to use versioned links within
templates for WebJars resources, such as `/jquery/1.2.0/jquery.js`.
This can be rather cumbersome when updating libraries - all references
in templates need to be updated.
One could use version-less links in templates, but needed to add a
specific MVC Handler that uses webjars.org's webjar-locator library.
While this approach makes maintaing templates easier, this makes HTTP
caching strategies less optimal.
This commit adds a new WebJarsResourceResolver that search for resources
located in WebJar locations. This ResourceResolver is automatically
registered if the "org.webjars:webjars-locator" dependency is present.
Registering WebJars resource handling can be done like this:
```java
@Override
protected void addResourceHandlers(ResourceHandlerRegistry registry) {
registry.addResourceHandler("/webjars/**")
.addResourceLocations("classpath:META-INF/resources/webjars")
.resourceChain(true)
.addResolver(new WebJarsResourceResolver());
}
```
Issue: SPR-12323
polish
Prior to this commit, registering `HandlerInterceptor`s using the
`InterceptorRegistry` would not guarantee their order of execution. In
fact, `HandlerInterceptor`s would always be executed before
`MappedInterceptor`s.
This change makes `MappedInterceptor` implement the `HandlerInterceptor`
interface, in order to register all interceptors in a single ordered
list. The order of execution of interceptors is now guaranteed in the
`HandlerExecutionChain` built by `AbstractHandlerMapping`.
Issue: SPR-12673
This commit introduces support for OkHttp
(http://square.github.io/okhttp/) as a backing implementation for
ClientHttpRequestFactory and AsyncClientHttpRequestFactory.
Issue: SPR-12893
MvcUriComponentsBuilder::fromMethodCall creates wrong URLs with derived
controller classes. The @RequestMapping of the declaring class of the
method that is called is used instead of the @RequstMapping of the
given controller class.
https://jira.spring.io/browse/SPR-13033
After this change CorsProcessor has a single processRequest method and
it also explicitly deals with a null CorsConfiguration, which for
pre-flight requests results in a rejection while for simple requests
results in no CORS headers added.
The AbstractHandlerMapping now uses a LinkedHashMap to preserve the
order in which global patterns are provided.
In order to simplify configuration of the SpringMethodRule and to ensure
that the correct TestContextManager is always retrieved for the
currently executing test class, this commit introduces a static
TestContextManager cache in SpringClassRule.
In addition, since it is not foreseen that SpringClassRule and
SpringMethodRule should be able to be subclassed, their internal methods
are now private instead of protected.
Issue: SPR-7731
Since Spring Framework 2.5, support for integrating the Spring
TestContext Framework (TCF) into JUnit 4 based tests has been provided
via the SpringJUnit4ClassRunner, but this approach precludes the
ability for tests to be run with alternative runners like JUnit's
Parameterized or third-party runners such as the MockitoJUnitRunner.
This commit remedies this situation by introducing @ClassRule and @Rule
based alternatives to the SpringJUnit4ClassRunner. These rules are
independent of any Runner and can therefore be combined with
alternative runners.
Due to the limitations of JUnit's implementation of rules, as of JUnit
4.12 it is currently impossible to create a single rule that can be
applied both at the class level and at the method level (with access to
the test instance). Consequently, this commit introduces the following
two rules that must be used together.
- SpringClassRule: a JUnit TestRule that provides the class-level
functionality of the TCF to JUnit-based tests
- SpringMethodRule: a JUnit MethodRule that provides the
instance-level and method-level functionality of the TCF to
JUnit-based tests
In addition, this commit also introduces the following new JUnit
Statements for use with rules:
- RunPrepareTestInstanceCallbacks
- ProfileValueChecker
Issue: SPR-7731
This commit adds JavaConfig based global CORS configuration
capabilities to Spring MVC. It is now possible to specify
multiple CORS configurations, each mapped on a path pattern,
by overriding
WebMvcConfigurerAdapter#configureCrossOrigin(CrossOriginConfigurer).
It is also possible to combine global and @CrossOrigin based
CORS configuration.
Issue: SPR-12933
Prior to this commit, the documentation in AnnotationUtils was
inconsistent, and at times even misleading, with regard to finding
annotations that are "present" or "directly present" on annotated
elements.
This commit defines the terminology used within AnnotationUtils and
introduces the explicit notion of "meta-present" to denote that
annotations are present within annotation hierarchies above annotated
elements.
Issue: SPR-13030
This change introduces a strategy for expanding a URI template into a
URI and makes it a property of the RestTemplate and AsyncRestTemplate
so that they can be pre-configured with such a strategy.
The DefaultUriTemplateHandler relies on UriComponentsBuilder internally
and provides functionality equivalent to using the UriTemplate.
A DefaultUriTemplateHandler can also be configured to parse the path
of a URI template into path segments in order to allow expanding URI
variables according to path segment encoding rules.
Issue: SPR-12750
This commit updates code that previously used getAnnotationAttributes()
in AnnotatedElementUtils to use findAnnotationAttributes(), where
appropriate.
Issue: SPR-12738
This commit updates the "get semantics" search algorithm used in
`AnnotatedElementUtils` so that locally declared 'composed annotations'
are favored over inherited annotations.
Specifically, the internal `searchWithGetSemantics()` method now
searches locally declared annotations before searching inherited
annotations.
All TODOs in `AnnotatedElementUtilsTests` have been completed, and all
ignored tests have been reinstated.
Issue: SPR-11598
Prior to this commit, the ResourceUrlEncodingFilter would fail with a
StringIndexOutOfBoundsException when:
* the current request has a servlet context
* the URL to encode is relative and is shorter than the context value
This change defensively checks for those lengths and delegates to the
parent implementation if necessary.
Issue: SPR-13018
This change introduces SimpUserRegistry exposing an API to access
information about connected users, their sessions, and subscriptions
with STOMP/WebSocket messaging. Provides are methods to access users
as well as a method to find subscriptions given a Matcher strategy.
The DefaultSimpUserRegistry implementation is also a
SmartApplicationListener which listesn for ApplicationContext events
when users connect, disconnect, subscribe, and unsubscribe to
destinations.
The MultiServerUserRegistry implementation is a composite that
aggregates user information from the local SimpUserRegistry as well
as snapshots of user on remote application servers.
UserRegistryMessageHandler is used with MultiServerUserRegistry. It
broadcats user registry information through the broker and listens
for similar broadcasts from other servers. This must be enabled
explicitly when configuring the STOMP broker relay.
The existing UserSessionRegistry which was primiarly used internally
to resolve a user name to session id's has been deprecated and is no
longer used. If an application configures a custom UserSessionRegistr
still, it will be adapted accordingly to SimpUserRegistry but the
effect is rather limited (comparable to pre-existing functionality)
and will not work in multi-server scenarios.
Issue: SPR-12029
This commit improves the documentation for AnnotationUtils and
AnnotatedElementUtils by explaining that the scope of most annotation
searches is limited to finding the first such annotation, resulting in
additional such annotations being silently ignored.
Issue: SPR-13015
Spring Framework's build is using a custom MergePlugin in order to merge
a project into another one and share/override configuration and
dependencies.
Prior to this commit, two projects merged into a third one could trigger
dependency conflicts when exporting the project definition into a POM.
When trying to define the scope for a given dependency, those two
projects would compete for this with the same priority, resulting in a
Gradle exception.
One could trigger this issue by running:
./gradlew :spring-orm:install -x javadoc
Because `spring-orm-hibernate4` and `spring-orm-hibernate5` get merged
into `spring-orm` and both define optional/test dependencies to
spring-mvc, etc.
This commit makes sure that two projects, when defining dependency
scopes, don't use the same priority value; the MergePlugin now adds the
index of the current subproject to the priority value. So when two
projects compete for this, the one defined in last will define the
dependency scope.
Issue: SPR-13013
In general, the Spring Framework aims to construct error message
strings only if an actual error has occurred. This seems to be the
common pattern in the codebase and saves both CPU and memory. However,
there are some places where eager error message formatting occurs
unnecessarily.
This commit addresses this issue in the following classes:
AdviceModeImportSelector, AnnotationAttributes, and
ReadOnlySystemAttributesMap.
The change in ReadOnlySystemAttributesMap also avoids a potential
NullPointerException.
Issue: SPR-13007
This commit introduces support in the spring-test module for obtaining a
reference to the underlying target object hidden behind one or more
proxies.
Specifically this commit introduces AopTestUtils with two methods:
- getTargetObject(Object)
- getUltimateTargetObject(Object)
Issue: SPR-13005
Commit 5648fbfc31 introduced a
compile-time dependency on spring-beans-groovy in the spring-context
module which breaks the build on the CI server since the Animal Sniffer
task cannot find a JAR file for spring-beans-groovy.
This commit reverts that change so that the "sniffer" task once again
succeeds.
Prior to this commit, the `getAnnotation()` method in `TypeDescriptor`
only supported a single level of meta-annotations. In other words, the
annotation hierarchy would not be exhaustively searched.
This commit provides support for arbitrary levels of meta-annotations
in `TypeDescriptor` by delegating to `AnnotationUtils.findAnnotation()`
within `TypeDescriptor.getAnnotation()`.
Issue: SPR-12793
Prior to this commit, AntPathMatcher would not correctly combine a path
that ends with a separator with a path that starts with a separator.
For example, `/foo/` + `/bar` combined into `/foo//bar`.
Specifically, this commit:
- Removes the duplicated separator in combined paths
- Improves RequestMappingInfo's toString() representation
- Fixes Javadoc formatting in AntPathMatcher
- Polishes AntPathMatcherTests
- Polishes Javadoc in AbstractRequestCondition
Issue: SPR-12975
This commit introduces a messaging.converter.MessageConverter that
marshals to/from XML using the abstractions provided in the OXM module.
Issue: SPR-12726
Prior to this change, the `UrlTag` would simply append the remote
context and the path value in case of a context relative URL.
The following code snippet would output "//foo":
```
<spring:url value="/foo" context="/" />
```
This change now removes trailing slashes in remote context to avoid
this.
Issue: SPR-12782
Making sure that `GenericApplicationListenerAdapter` implements
`SmartApplicationListener` again as older code may try to cast an
instance to `SmartApplicationListener`.
Issue: SPR-8201
This commit picks up where SPR-11483 left off, with the goal of
eliminating all unnecessary inspection of core JDK annotations in
Spring's annotation search algorithms in AnnotatedElementUtils and
AnnotationMetadataReadingVisitor.
Issue: SPR-12989
- Methods which search for a specific annotation now properly ensure
that the sought annotation was actually found.
- Both the "get" and the "find" search algorithms no longer needlessly
traverse meta-annotation hierarchies twice.
- Both the "get" and the "find" search algorithms now properly
increment the metaDepth when recursively searching within the
meta-annotation hierarchy.
- Redesigned getMetaAnnotationTypes() so that it doesn't needlessly
search irrelevant annotations.
- Documented and tested hasMetaAnnotationTypes().
- Documented isAnnotated().
Issue: SPR-11514
Before this change AbstractHandlerMethodMapping used a map from Method
to CorsConfiguration. That works for regular @RequestMapping methods.
However frameworks like Spring Boot and Spring Integration may
programmatically register the same Method under multiple mappings,
i.e. adapter/gateway type classes.
This change ensures that CorsConfiguraiton is indexed by HandlerMethod
so that we can store CorsConfiguration for different handler instances
even when the method is the same.
In order for to make this work, HandlerMethod now provides an
additional field called resolvedFromHandlerMethod that returns the
original HandlerMethod (with the String bean name). This makes it
possible to perform reliable lookups.
Issue: SPR-11541
This commit introduces failing (but currently disabled) test cases in
HandlerMethodAnnotationDetectionTests that attempt to reproduce the
scenario described in SPR-9517.
See: ParameterizedSubclassDoesNotOverrideConcreteImplementationsFromGenericAbstractSuperclass
Furthermore, this commit also introduces passing tests cases for a
similar scenario. See: ParameterizedSubclassOverridesDefaultMappings
Issue: SPR-9517
Since SPR-10954, the SimpleBrokerMessageHandler supports `heart-beats`.
Even if the STOMP spec states that the `heart-beat` header is OPTIONAL,
and if absent considered as `heart-beat: 0,0`,
some clients rely on this to be set in CONNECTED frames.
This commit adds this header information even if no task
scheduler/heart-beat have been configured.
See: https://stomp.github.io/stomp-specification-1.2.html#Heart-beating
Issue: SPR-10954
Do not refer to deprecated ParameterizedBeanPropertyRowMapper in reference manual
Change to the BeanPropertyRowMapper from the ParameterizedBeanPropertyRowMapper
CorsConfiguration now provides methods to check and determine the
allowed origin, method, and headers according to its own configuration.
This simplifies significantly the work that needs to be done from
DefaultCorsProcessor. However an alternative CorsProcessor can still
access the raw CorsConfiguration and perform its own checks.
Issue: SPR-12885
This commit adds CORS related headers to HttpHeaders
and update DefaultCorsProcessor implementation to
use ServerHttpRequest and ServerHttpResponse instead
of HttpServletRequest and HttpServletResponse. Usage
of ServerHttpResponse allows to avoid using Servlet 3.0
specific methods in order keep CORS support Servlet 2.5
compliant.
Issue: SPR-12885
The change to provide public register/unregister methods in
AbstractHandlerMethodMapping assumed that a single method cannot be
mapped more than once. This is not the case with the MvcEndpoints and
EndpointHandlerMapping from Spring Boot which wrap one or more
non-web Endpoint types with an MvcEndpointAdapter in order to expose
them for use over the web. In effect Spring MVC sees a single handler
method mapped many times.
This change removes that assumption so rather than unregistering with
a HandlerMethod, which is not necessarily unique, the unregister method
now takes the actual mapping, which is the only thing that should actually
be unique.
Issue: SPR-11541
This commit adds additional context to the exception message generated
when two candidate methods are discovered in MvcUriComponentsBuilder's
getMethod(Class<?>, String, Object...).
Issue: SPR-12977
This commit introduces a new fromMethodNameWithBridgedMethod() test in
MvcUriComponentsBuilderTests which is currently disabled via @Ignore
until this bug is resolved.
Issue: SPR-12977
When used in combination with GzipResourceResolver, the
CachingResourceResolver does not properly cache results, since it only
takes the request path as a input for cache key generation.
Here's an example of that behavior:
1. an HTTP client requests a resource with `Accept-Encoding: gzip`, so
the GzipResourceResolver can resolve a gzipped resource.
2. the configured CachingResourceResolver caches that resource.
3. another HTTP client requests the same resource, but it does not
support gzip encoding; the previously cached gzipped resource is still
returned.
This commit uses the presence/absence of gzip encoding support as an
input in cache keys generation.
Issue: SPR-12982
Before this change AbstractHandlerMethodMapping contained multiple
maps all containing different kinds of mapping meta-data. After the
change a MappingDefinitionRegistry inner class encapsulates these
fields along with their initialization code.
Issue: SPR-11541
This commit documents the status quo for the getMetaAnnotationTypes()
method in AnnotatedElementUtils and adds appropriate regression tests to
AnnotatedElementUtilsTests.
In addition, this commit also introduces a SimpleAnnotationProcessor
base class in AnnotatedElementUtils.
Issue: SPR-11514
Prior to this commit it was possible for two @BootstrapWith annotations
to be 'present' on a test class -- for example, via competing custom
composed annotations. However, only one of the annotations will ever be
used to bootstrap the TestContext Framework. Thus, in such scenarios
one of the annotations will be silently ignored.
This commit introduces a check for such scenarios. BootstrapUtils'
resolveTestContextBootstrapper() method now throws an
IllegalStateException if more than one @BootstrapWith annotation is
'present' on a given test class.
Issue: SPR-12602
This commit consistently documents the 'element' and 'annotationType'
method arguments throughout AnnotatedElementUtils.
In addition, this commit introduces assertions against preconditions
for all 'element' and 'annotationType' method arguments.
Issue: SPR-11514
Previously MockHttpServletRequestBuilder merge method would append the
parent's (default) RequestPostProcessor implementations to the end. This
means that the default RequestPostProcessor implementations would override
values set by previous RequestPostProcessor implementations.
This commit ensures that the default RequestPostProcessor are preformed
first so that additional RequestPostProcessor implementations override
the defaults.
Issue: SPR-12945
This commit introduces support for finding annotations on abstract,
bridge, and interface methods in AnnotatedElementUtils.
- Introduced dedicated findAnnotationAttributes() methods in
AnnotatedElementUtils that provide first-class support for
processing methods, class hierarchies, interfaces, bridge methods,
etc.
- Introduced find/get search algorithm dichotomy in
AnnotatedElementUtils which is visible in the public API as well as
in the internal implementation. This was necessary in order to
maintain backwards compatibility with the existing API (even though
it was undocumented).
- Reverted all recent changes made to the "get semantics" search
algorithm in AnnotatedElementUtils in order to ensure backwards
compatibility, and reverted recent changes to
JtaTransactionAnnotationParser and SpringTransactionAnnotationParser
accordingly.
- Documented internal AnnotatedElementUtils.Processor<T> interface.
- Enabled failing tests and introduced
findAnnotationAttributesFromBridgeMethod() test in
AnnotatedElementUtilsTests.
- Refactored ApplicationListenerMethodAdapter.getCondition() and
enabled failing test in TransactionalEventListenerTests.
- AnnotationUtils.isInterfaceWithAnnotatedMethods() is now package
private.
Issue: SPR-12738, SPR-11514, SPR-11598
Before 4.2 the MvcUriComponentsBuilder exposed only static factory
methods and therefore there should be no reason for it to extend
UriComponentsBuilder (design oversight). It's also highly unlikely
for application code to treat MvcUriCB as UriCB since there is no
need and no way to obtain an instance (constructor is protected).
This change removes the base class declaration from MvcUriCB.
Issue: SPR-12617
Before this change MvcUriComponentsBuilder exposed only static factory
methods for creating links where the links are relative to the current
request or a baseUrl explicitly provided as an argument.
This change allows creating an MvcUriComponents builder instance with
a built-in baseUrl. The instance can then be used with non-static
withXxx(...) method alternatives to the static fromXxx(...) methods.
Issue: SPR-12617
Prior to this commit, AnnotationAttributes retrieved from
MetaAnnotationUtils's AnnotationDescriptor could contain attributes
from the wrong annotation if an inherited annotation shadowed a locally
declared composed annotation.
This commit addresses this issue by invoking the new
getAnnotationAttributes() method in AnnotatedElementUtils that provides
a flag to control whether superclasses should be searched -- which
coincidentally processes local annotations before searching the class
hierarchy.
Issue: SPR-12749, SPR-11598
This commit introduces support in AnnotatedElementUtils for finding
annotations declared on interfaces at the type level.
NB: this commit does not include support for finding annotations
declared on interface methods.
In order to maintain backward compatibility with @Transactional
annotation attribute processing, a new getAnnotationAttributes() method
has been added to AnnotatedElementUtils that provides a flag to control
whether interfaces should be searched.
SpringTransactionAnnotationParser and JtaTransactionAnnotationParser
have been updated accordingly to ensure that interfaces are not
unintentionally searched in the @Transactional resolution process.
This commit also introduces additional tests and updates TODOs for
SPR-12738.
Issue: SPR-12944, SPR-12738
This commit adds support for script based templating. Any templating
library running on top of a JSR-223 ScriptEngine that implements
Invocable like Nashorn or JRuby could be used.
For example, in order to render Mustache templates thanks to the Nashorn
Javascript engine provided with Java 8+, you should declare the following
configuration:
@Configuration
@EnableWebMvc
public class MustacheConfig extends WebMvcConfigurerAdapter {
@Override
public void configureViewResolvers(ViewResolverRegistry registry) {
registry.scriptTemplate();
}
@Bean
public ScriptTemplateConfigurer configurer() {
ScriptTemplateConfigurer configurer = new ScriptTemplateConfigurer();
configurer.setEngineName("nashorn");
configurer.setScripts("mustache.js");
configurer.setRenderObject("Mustache");
configurer.setRenderFunction("render");
return configurer;
}
}
The XML counterpart is:
<beans>
<mvc:annotation-driven />
<mvc:view-resolvers>
<mvc:script-template />
</mvc:view-resolvers>
<mvc:script-template-configurer engine-name="nashorn" render-object="Mustache" render-function="render">
<mvc:script location="mustache.js" />
</mvc:script-template-configurer>
</beans>
Tested with:
- Handlebars running on Nashorn
- Mustache running on Nashorn
- React running on Nashorn
- EJS running on Nashorn
- ERB running on JRuby
- String templates running on Jython
Issue: SPR-12266
Prior to this commit, the search algorithm used by the
findAnnotation(Method, Class) method in AnnotationUtils only found
direct annotations or direct meta-annotations (i.e., one level of
meta-annotations).
This commit reworks the search algorithm so that it supports arbitrary
levels of meta-annotations on methods. To make this possible, a new
findAnnotation(AnnotatedElement, Class) method has been introduced in
AnnotationUtils.
This fix also allows for the @Ignore'd tests in
TransactionalEventListenerTests to be re-enabled.
Issue: SPR-12941
Since the ContextCache is now a published SPI, it and its collaborators
have been moved to a dedicated 'org.sfw.test.context.cache' subpackage.
Issue: SPR-12683
If a custom MessageConverter is set, it is not used for replies defined
via the Message abstraction. This commit harmonizes the behaviour of the
`MessagingMessageConverter` so that the conversion of the payload can
be converted for both incoming and outgoing messages.
Issue: SPR-12912
Previously, a custom `DestinationResolver` was not made available
to the underlying `MessageListener`: if a reply needs to be sent, the
default `DestinationResolver` was used.
This commit ensures that if a custom `DestinationResolver` has been set,
it is also configured accordingly for replies.
Issue: SPR-12927
This commit adds an assertion to DefaultTestContext's
getApplicationContext() method to ensure that a context loaded by the
Spring TestContext Framework (TCF) or retrieved from the ContextCache
is still active. This extra check helps to avoid situations where
developers manually close a cached context instead of relying on the
@DirtiesContext support.
Issue: SPR-12932
The changes made in 0cb22fc8f3 would
result in contexts not being properly closed if evicted from the
ConcurrentReferenceHashMap by the Garbage Collector.
This commit reverts those changes and returns to using standard
ConcurrentHashMaps for the time being.
Issue: SPR-7687
Improve extensibility of TestContext bootstrapping & context caching
These commits include numerous refactorings and enhancements to the
bootstrapping and context caching mechanisms in the Spring TestContext
Framework.
Issue: SPR-12683
- DefaultBootstrapContext and DefaultCacheAwareContextLoaderDelegate
are now public classes in the 'support' subpackage.
- Introduced getCacheAwareContextLoaderDelegate() in
AbstractTestContextBootstrapper as an extension point for configuring
custom ContextCache support.
- Introduced reflection-based createBootstrapContext() utility method
in BootstrapUtils; TestContextManager now delegates to BootstrapUtils
in order to avoid package cycles.
- Introduced logStatistics() method in the ContextCache API and defined
statistics logging category as a constant.
- DefaultCacheAwareContextLoaderDelegate now delegates to
ContextCache.logStatistics().
Issue: SPR-12683
This commit moves the responsibility of building a TestContext from the
TestContextManager to a TestContextBootstrapper.
In addition, DefaultTestContext is now a public class residing in the
"support" subpackage.
Issue: SPR-12683
Prior to this commit, the ContextCache in the Spring TestContext
Framework (TCF) cached ApplicationContexts in a ConcurrentHashMap using
strong references. This practice can occasionally lead to
OutOfMemoryErrors when running a large number of tests in a test suite
with varying context configuration since the context cache becomes
overpopulated over time.
This commit addresses this issue by using Spring's
ConcurrentReferenceHashMap which uses SoftReferences for both the keys
(i.e., MergedContextConfiguration instances) and values (i.e.,
ApplicationContexts) stored in the map that backs the ContextCache.
Issue: SPR-7687
This change adds support for broadcasting messages with unresolved
user destinations so that other servers can try to resolve it.
That enables sending messages to users who may be connected to a
different server.
Issue: SPR-11620
Prior to this commit, ClassLevelDirtiesContextTests existed for
verifying the expected behavior of @DirtiesContext declared at the
class level in conjunction with JUnit and SpringJUnit4ClassRunner.
This commit introduces analogous tests for TestNG in the new
ClassLevelDirtiesContextTestNGTests class.
Furthermore, ContextCacheTestUtils and TrackingTestNGTestListener have
been introduced to reduce code duplication across the test suite.
Issue: SPR-12918
The attributes of @JmsListener allows to specify the reference to a key
in the Environment but @SendTo did not.
This commit fixes this inconsistency so that response destinations are
now also externally configurable.
Issue: SPR-12899
Previously, the "pubSubDomain" drove the resolution of both the
destination of the listener and the default response destination.
A new "replyPubSubDomain" attribute has been added on the base listener
and can be used to listen on a topic and reply to a queue (or vice
versa). The attribute is exposed via the "response-destination-type" XML
attribute on the listener container element. It is also available on the
JmsListenerContainerFactory for use with the @JmsListener infrastructure.
Issue: SPR-12911
This commit increases the extensibility of
AbstractTestContextBootstrapper by making the resolveContextLoader()
and resolveExplicitContextLoaderClass() methods protected instead of
private.
Furthermore, resolveContextLoader() now throws an IllegalStateException
if getDefaultContextLoaderClass() returns null.
Issue: SPR-12682
This commit improves the documentation for ScriptUtils by explicitly
mentioning that a JDBC Connection supplied to the one of the
executeSqlScript() methods will not be released automatically.
Issue: SPR-12908
The onFailure callback and future.get() occur in different threads so
this change adds a latch to ensure we have both before asserting.
Issue: SPR-12887
AbstractHttpMessageConverter now tries to call getDefaultContentType
with the actual value to be converted to see if that will result in
a more concrete mediat type than application/octet-stream.
Issue: SPR-12894
The use of RedirectAttributes was documented in four places in the
reference documentation. This commit merges some of the places and links
properly between them.
Issue: SPR-12759
Prior to this commit it was possible to set or get a static field using
ReflectionTestUtils but only if an instance of the target class was
available.
This commit introduces dedicated support for setting and getting static
fields in ReflectionTestUtils when only the target class is available.
Furthermore, this commit increases the robustness of
ReflectionTestUtilsTests regarding expected exceptions and simplifies
the Javadoc for ReflectionTestUtils.
Issue: SPR-6792
The auto startup flag can now be set on a JmsListenerContainerFactory to
control if the created container should be started automatically when the
application context starts.
Issue: SPR-12824
This commit introduces support for CORS in Spring Framework.
Cross-origin resource sharing (CORS) is a mechanism that allows
many resources (e.g. fonts, JavaScript, etc.) on a web page to
be requested from another domain outside the domain from which
the resource originated. It is defined by the CORS W3C
recommandation (http://www.w3.org/TR/cors/).
A new annotation @CrossOrigin allows to enable CORS support
on Controller type or method level. By default all origins
("*") are allowed.
@RestController
public class SampleController {
@CrossOrigin
@RequestMapping("/foo")
public String foo() {
// ...
}
}
Various @CrossOrigin attributes allow to customize the CORS configuration.
@RestController
public class SampleController {
@CrossOrigin(origin = { "http://site1.com", "http://site2.com" },
allowedHeaders = { "header1", "header2" },
exposedHeaders = { "header1", "header2" },
method = RequestMethod.DELETE,
maxAge = 123, allowCredentials = "true")
@RequestMapping(value = "/foo", method = { RequestMethod.GET, RequestMethod.POST} )
public String foo() {
// ...
}
}
A CorsConfigurationSource interface can be implemented by HTTP request
handlers that want to support CORS by providing a CorsConfiguration
that will be detected at AbstractHandlerMapping level. See for
example ResourceHttpRequestHandler that implements this interface.
Global CORS configuration should be supported through ControllerAdvice
(with type level @CrossOrigin annotated class or class implementing
CorsConfigurationSource), or with XML namespace and JavaConfig
configuration, but this is not implemented yet.
Issue: SPR-9278
This commit adds a filters property to MappingJacksonValue
and also manages a special FilterProvider class name model key in
order to be able to specify a customized FilterProvider for each
handler method execution, and thus provides a more dynamic
alternative to our existing JsonView support.
A filters property is also now available in Jackson2ObjectMapperBuilder
and Jackson2ObjectMapperFactoryBean in order to set easily a
global FilterProvider.
More details about @JsonFilter at
http://wiki.fasterxml.com/JacksonFeatureJsonFilter.
Issue: SPR-12586
Prior to this commit, the `client-library-url` XML attribute was not
effective in the MVC namespace, leaving the default value configured:
```xml
<websocket:sockjs client-library-url="/js/sockjs.js" />
```
This commit fixes the sockjs namespace handler and makes sure that this
attribute is configured on the `SockJsService` Bean to be created.
Issue: SPR-12874
This commit introduces support for "Path Segment URI Variable
expansion", see https://tools.ietf.org/html/rfc6570#section-3.2.6.
In practice, this means that URI template variables prefixed with a '/'
are treated like path segments and - as such - will encode any '/'
found. For example: {/foo} expanded with "bar/baz" with result in
"bar%2F".
Issue: SPR-12750
This change provides support for map[NEW], map[new], map[T]
and map[t]. Prior to this change the 'new' and 't' had to
be quoted because they were keywords in SpEL for a constructor
reference and type reference respectively.
Issue: SPR-11783
- The exception message now mentions lacking to-Object method as well.
- Documented explicit lacking support for toString() for conversions.
- Introduced dedicated has*() methods for greater clarity and to reduce
code duplication.
- Static factory methods (i.e., of, from, valueOf) are now supported for
conversion to a String.
- Now correctly using @Test(expected=...) where appropriate.
- Renamed DefaultConversionTests to DefaultConversionServiceTests.
- Moved all tests related to DefaultConversionService from
GenericConversionServiceTests to DefaultConversionServiceTests.
- No longer printing to System.out.
- Removed all duplicate instantiation of conversion services.
- Now using Java 8 streams to simplify implementations of custom test
converters. Also using streams in tests where appropriate.
The check for an empty request body InputStream is now in the base
class AbstractMessageConverterMethodArgumentResolver shared for
all arguments that involve reading with an HttpMessageConverter --
@RequestBody, @RequestPart, and HttpEntity.
When an empty body is detected any configured RequestBodyAdvice is
given a chance to select a default value or leave it as null.
Issue: SPR-12778, SPR-12860, SPR-12861
RequestBodyAdvice is analogous to ResponseBodyAdvice (added in 4.1)
but for intercepting for reading the request with an
HttpMessageConverter for resolving an @RequestBody or an HttpEntity
method argument.
Issue: SPR-12501
The rework of 314b069 in a7fec6a has created a lazy proxy to make sure
that the need for an exception cache resolver come as late as possible.
Unfortunately, the test that was only failing on CI because of an early
lookup has not been updated accordingly. This is now the case.
Issue: SPR-12850
This is a rework of 314b069 that may still lead to issue if a Cacheable
annotated bean is inspected on startup. Instead of resolving the default
exception CacheResolver if a cache operation is parsed, we resolve it as
late as possible (i.e. when an exception is thrown and the relevant
exception cache needs to be resolved)
Issue: SPR-12850
Previously, a cache infrastructure with only a CacheResolver would have
worked fine until the JSR-107 API is added to the classpath. When this is
the case, the JCache support kicks in and an exception cache resolver is
all of the sudden required.
The CacheResolver _is_ different as the default implementation does look
different attributes so if a custom CacheResolver is set, it is not
possible to "reuse" it as a fallback exception CacheResolver.
Now, an exception CacheResolver is only required if a JSR-107 annotation
with an "exceptionCacheName" attribute is processed (i.e. the exception
CacheResolver is lazily instantiated if necessary).
The use case of having a CachingConfigurerSupport with only a
CacheResolver was still broken though since the JCache support only looks
for a JCacheConfigurer bean (per the generic type set on
AbstractCachingConfiguration). This has been fixed as well.
Issue: SPR-12850
The getter in TransportHandlingSockJsService now returns a mutable
List. The immutable wrapper doesn't make sense since it's possible
anyway to modify the list by creating a new list and calling the
setter again. It's also consistent with the same field on
WebSocketHttpRequestHandler.
This is related to work for SPR-12845.
Generally update chapter and add documentation for 4.2 including
the return value types ResponseBodyEmitter, SseEmitter, and
StreamingResponseBody.
Issue: SPR-12672
This reverts commit a57d42829c after the
realization of a weaknesses with the proposed approach.
For example if a path segment contains both a /-prefixed and a regular
URI variable, there is no way to split that into a sequence of path
and path segments. The solution will have to be on the side of
UriComponents at the time of encoding.
Introduces an AbstractXlsView and dedicated subclasses for POI's xmlx support.
Deprecates the traditional AbstractExcelView which is based on pre POI 3.5 API.
Issue: SPR-6898
Since SPR-11792, Last-Modified and ETag headers are also written in
`HTTP 304 Not Modified` responses. This is expected as per
https://tools.ietf.org/html/rfc7232#section-4.1 .
Those tests expected "Last-Modified" to be missing in case of HTTP 304
responses, which is not the case anymore since 953608ec .
Issue: SPR-11792
The `javadoc-baseurl` asciidoctor attribute is now externalized
(i.e. not included directly in the document anymore).
This allows to properly render javadoc links in single pages, whereas
those URLs were previoulsy only supported in the single page version.
Prior to this commit, Cache-Control HTTP headers could be set using
a WebContentInterceptor and configured cache mappings.
This commit adds support for cache-related HTTP headers at the controller
method level, by returning a ResponseEntity instance:
ResponseEntity.status(HttpStatus.OK)
.cacheControl(CacheControl.maxAge(1, TimeUnit.HOURS).cachePublic())
.eTag("deadb33f8badf00d")
.body(entity);
Also, this change now automatically checks the "ETag" and
"Last-Modified" headers in ResponseEntity, in order to respond HTTP
"304 - Not Modified" if necessary.
Issue: SPR-8550
This commit improves HTTP caching defaults and flexibility in
Spring MVC.
1) Better default caching headers
The `WebContentGenerator` abstract class has been updated with
better HTTP defaults for HTTP caching, in line with current
browsers and proxies implementation (wide support of HTTP1.1, etc);
depending on the `setCacheSeconds` value:
* sends "Cache-Control: max-age=xxx" for caching responses and
do not send a "must-revalidate" value by default.
* sends "Cache-Control: no-store" or "Cache-Control: no-cache"
in order to prevent caching
Other methods used to set specific header such as
`setUseExpiresHeader` or `setAlwaysMustRevalidate` are now deprecated
in favor of `setCacheControl` for better flexibility.
Using one of the deprecated methods re-enables previous HTTP caching
behavior.
This change is applied in many Handlers, since
`WebContentGenerator` is extended by `AbstractController`,
`WebContentInterceptor`, `ResourceHttpRequestHandler` and others.
2) New CacheControl builder class
This new class brings more flexibility and allows developers
to set custom HTTP caching headers.
Several strategies are provided:
* `CacheControl.maxAge(int)` for caching responses with a
"Cache-Control: max-age=xxx" header
* `CacheControl.noStore()` prevents responses from being cached
with a "Cache-Control: no-store" header
* `CacheControl.noCache()` forces caches to revalidate the cached
response before reusing it, with a "Cache-Control: no-store" header.
From that point, it is possible to chain method calls to craft a
custom CacheControl instance:
```
CacheControl cc = CacheControl.maxAge(1, TimeUnit.HOURS)
.cachePublic().noTransform();
```
3) Configuring HTTP caching in Resource Handlers
On top of the existing ways of configuring caching mechanisms,
it is now possible to use a custom `CacheControl` to serve
resources:
```
@Configuration
public class MyWebConfig extends WebMvcConfigurerAdapter {
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
CacheControl cc = CacheControl.maxAge(1, TimeUnit.HOURS);
registry.addResourceHandler("/resources/**)
.addResourceLocations("classpath:/resources/")
.setCacheControl(cc);
}
}
```
or
```
<mvc:resources mapping="/resources/**" location="classpath:/resources/">
<mvc:cachecontrol max-age="3600" cache-public="true"/>
</mvc:resources>
```
Issue: SPR-2779, SPR-6834, SPR-7129, SPR-9543, SPR-10464
This change improves the following use cases with
`WebRequest.checkNotModified(String etag)` and
`WebRequest.checkNotModified(long lastModifiedTimeStamp)`:
1) Allow weak comparisons for ETags
Per rfc7232 section-2.3, ETags can be strong or weak;
this change allows comparing weak forms `W/"etagvalue"` but does
not make a difference between strong and weak comparisons.
2) Allow multiple ETags in client requests
HTTP clients can send multiple ETags values in a single header such as:
`If-None-Match: "firstvalue", "secondvalue"`
This change makes sure each value is compared to the one provided by
the application side.
3) Extended support for ETag values
This change adds padding `"` to the ETag value provided by
the application, if not already done:
`etagvalue` => `"etagvalue"`
It also supports wildcard values `*` that can be sent by HTTP clients.
4) Sending validation headers for 304 responses
As defined in https://tools.ietf.org/html/rfc7232#section-4.1
`304 Not Modified` reponses must generate `Etag` and `Last-Modified`
HTTP headers, as they would have for a `200 OK` response.
5) Providing a new method to validate both Etag & Last-Modified
Also, this change adds a new method
`WebRequest.checkNotModified(String etag, long lastModifiedTimeStamp)`
in order to support validation of both `If-None-Match` and
`Last-Modified` headers sent by HTTP clients, if both values are
supported by the application code.
Even though this approach is recommended by the HTTP rfc (setting both
Etag and Last-Modified headers in the response), this requires more
application logic and may not apply to all resources produced by the
application.
Issue: SPR-11324
Prior to this commit, @DirtiesContext could only be used to close a
test ApplicationContext after an entire test class or after a test
method; however, there are some use cases for which it would be
beneficial to close a test ApplicationContext before a given test class
or test method -- for example, if some rogue (i.e., yet to be
determined) test within a large test suite has corrupted the original
configuration for the ApplicationContext.
This commit provides a solution to such testing challenges by
introducing the following modes for @DirtiesContext.
- MethodMode.BEFORE_METHOD: configured via the new methodMode attribute
- ClassMode.BEFORE_CLASS and ClassMode.BEFORE_EACH_TEST_METHOD: both
configured via the existing classMode attribute
Issue: SPR-12429
Since Guava 11, CacheLoader is only invoked with a LoadingCache but the
GuavaCache wrapper is always invoking getIfPresent(), available on the
main Guava Cache interface.
Update GuavaCache#get to check for the presence of a LoadingCache and
call the appropriate method.
Issue: SPR-12842
This commit updates the Spr8849Tests test suite to include XML
configuration that guarantees that a unique database name is always
automatically generated (via the new 'generate-name' attribute that was
introduced in SPR-8849) while reusing the same bean name (i.e.,
'dataSource').
Issue: SPR-8849
Development teams often encounter errors with embedded databases if
their test suite inadvertently attempts to recreate additional
instances of the same database. This can happen quite easily if an XML
configuration file or @Configuration class is responsible for creating
an embedded database and the corresponding configuration is then reused
across multiple testing scenarios within the same test suite (i.e.,
within the same JVM process) -- for example, integration tests against
embedded databases whose ApplicationContext configuration only differs
with regard to which bean definition profiles are active.
The root cause of such errors is the fact that Spring's
EmbeddedDatabaseFactory (used internally by both the
<jdbc:embedded-database> XML namespace element and the
EmbeddedDatabaseBuilder for Java Config) will set the name of the
embedded database to "testdb" if not otherwise specified. For the case
of <jdbc:embedded-database>, the embedded database is typically
assigned a name equal to the bean's id. Thus, subsequent attempts to
create an embedded database will not result in a new database. Instead,
the same JDBC connection URL will be reused, and attempts to create a
new embedded database will actually point to an existing embedded
database created from the same configuration.
This commit addresses this common issue by introducing support for
generating unique names for embedded databases. This support can be
enabled via:
- EmbeddedDatabaseFactory.setGenerateUniqueDatabaseName()
- EmbeddedDatabaseBuilder.generateUniqueName()
- <jdbc:embedded-database generate-name="true" ... >
Issue: SPR-8849
This commit introduces support for HTTP byte ranges in the
ResourceHttpRequestHandler. This support consists of a number of
changes:
- Parsing of HTTP Range headers in HttpHeaders, using a new HttpRange
class and inner ByteRange/SuffixByteRange subclasses.
- MIME boundary generation moved from FormHttpMessageConverter to
MimeTypeUtils.
- writePartialContent() method introduced in ResourceHttpRequestHandler,
handling the byte range logic
- Additional partial content tests added to
ResourceHttpRequestHandlerTests.
Issue: SPR-10805
After this change UriComponentsBuilder#uriComponents method no longer
no longer copies from the given UriComponents but rather lets the
UriComponents instance copy itself to the UriComponentsBuilder.
This avoids the need for instanceof checks and also makes it possible
to distinguish between path and path segments, which otherwise is
internal knowledge of UriComponentsBuilder.
Issue: SPR-12742
Revised HandlerMethod.getBeanType() impl for both web and messaging.
In addition, HandlerMethods get created with the internal BeanFactory now.
Issue: SPR-12832
This commit refactors the XML configuration used by the tests in the
Spr8849Tests test suite so that a unique database name is always
generated (via the new 'database-name' attribute that was introduced in
SPR-12835) while reusing the same bean name (i.e., 'dataSource').
This is a much more robust alternative to the previous work-around
since the name of the DataSource does not randomly change across
application contexts, thus allowing proper autowiring by name and bean
referencing within XML configuration.
Issue: SPR-8849
Prior to this commit, the EmbeddedDatabaseBeanDefinitionParser set the
name of the embedded database that it configured to the value of its
'id'. This made it impossible to assign unique names to embedded
databases if the same bean 'id' (e.g, 'dataSource') was used across
multiple application contexts loaded within the same JVM, which is
often the case within an integration test suite. In contrast, the
EmbeddedDatabaseBuilder already provides support for setting the name
in Java Config. Thus there is a disconnect between XML and Java
configuration.
This commit addresses this issue by introducing a 'database-name'
attribute in <jdbc:embedded-database />. This allows developers to set
unique names for embedded databases -- for example, via a SpEL
expression or a property placeholder that is influenced by the current
active bean definition profiles.
Issue: SPR-12835
This commit modifies EmbeddedDatabaseBeanDefinitionParser so that the
<jdbc:embedded-database> XML namespace element can be declared as an
anonymous bean (i.e., without an explicit ID).
Issue: SPR-12834
This commit introduces spring-jdbc-4.2.xsd in order to support upcoming
changes to the JDBC XML namespace.
In addition, this commit polishes the XSD documentation with regard to
use cases for script execution.
FlashMap now has a single field reflecting the expiration time and
also provides accessors that can be used for serialization purposes.
Issue: SPR-12757
AbstractFlashMapManager no longer decodes the target query parameters
it needs to use to match to the request after the redirect.
Instead it stores query parameters as-is adn then relies on parsing the
encoded query string after the redirect.
Issue: SPR-12569
This change adds support for global @MessageExceptionHandler methods
with STOMP over WebSocket messages. Such methods can be added to
@ControllerAdvice annotated components, much like @ExceptionHandler
methods for Spring MVC.
Issue: SPR-12696
Covers ReflectionUtils.doWithMethods as well as affected annotation post-processors.
Includes an extension of MethodMetadata for the detection of @Bean default methods.
Issue: SPR-12822
Issue: SPR-10919
Prior to this commit, the ContentCachingRequestWrapper would immediately
consume the wrapped request's InputStream when asked for the cached
content; that caused several issues:
* the request body was read in memory even if it wasn't yet consumed by
the application, leading to inefficiencies.
* when requesting the InputStream, an empty InputStream was returned
since the original was already read.
This case only happened for form POSTs requests.
This commit makes sure that the wrapper does not alter the request
expected behavior:
* when getting the inputstream, it is wrapped in order to cache its
content
* when getting request parameters, the request body is cached and its
inputstream is consumed, as expected
Issue: SPR-12810
WebSocketStompClient can be used with any implementation of
org.springframework.web.socket.client.WebSocketClient, which includes
org.springframework.web.socket.sockjs.client.SockJsClient.
Reactor11TcpStompClient can be used with reactor-net and provides STOMP
over TCP. It's also possible to adapt other WebSocket and TCP client
libraries (see StompClientSupport for more details).
For example usage see WebSocketStompClientIntegrationTests.
Issue: SPR-11588
Various documentation improvements related to `@Configuration` and
`Bean`. Better describe how method parameter can be used to declare
dependencies of a particular bean. Also add an explicit mentions related
to "hard-wiring" of dependencies in configuration classes.
Issue: SPR-12773
If a sub-class of Future (such as ListenableFuture) is used as a return
type and an exception is thrown, the AsyncUncaughtExceptionHandler is
called. Now checking for any Future implementation instead of a faulty
strict matching.
Issue: SPR-12797
This commit ensures that @NumberFormat can be used as a
meta-annotation, as was already the case for @DateTimeFormat.
In addition, this commit polishes FormattingConversionServiceTests and
MvcNamespaceTests.
Issue: SPR-12743
Prior to this commit, the [ant:iajc] tasks logged numerous warnings
regarding incorrect classpath entries. The reason is that the classpath
was constructed with paths that do not physically exist in the file
system (e.g., for projects that do not have test classes or test
folders (yet)).
This commit picks up where ef75bd8 left off and addresses this issue by
assembling the runtime classpath passed to the iajc task with folders
and JARs that actually exist in the filesystem.
This commit reverts the changes made in 7bc44a9 so that developers who
do not use the Gradle daemon are not adversely affected by the explicit
JVM args that were introduced in that commit.
Developers who wish to run the build against JDK 9 with the Gradle
daemon can add the following to the gradle.properties file in their
'gradle user home' directory (e.g., ~/.gradle/gradle.properties):
org.gradle.daemon=true
org.gradle.jvmargs=-XX:MaxMetaspaceSize=1024m -Xmx1024m
See also: https://issues.gradle.org/browse/GRADLE-3256
Issue: SPR-12549
The upgrade to a more recent asciidoc format led to a bunch of of
broken Admonition as the text block now requires four equal signs while
previous versions tolerated only 3.
Issue: SPR-12791
Prior to this change the SpEL compiler would not compile mathematical
expressions where the operands were of differing types (e.g. int
and double). This required the expression writer to do the conversion
in the expression text. For example:
T(Integer).valueOf(someInt).doubleValue()/35d
With this commit the restriction is lifted and it is more like Java
so that you can simply do someInt/35d. The mathematical operators
affected are divide/plus/minus/multiply and modulus. This change
involved removing some guards so that the exitTypeDescriptor (the
trigger for whether compilation is allowed) is set more frequently
and enhancing bytecode generation to perform more sophisticated
conversion/coercion automatically.
Issue: SPR-12789
Core and Web chapters are important chapters in the Spring Framework
reference documentation, and splitting them in multiple files will
help to evolve the documentation while not creating too many files.
Issue: SPR-12309
The reference documentation is now organized in asciidoc bookparts.
Bookparts sections can be also put in separate files, when their
size and theme are important enough to justify that.
Documentation Layout:
```
index
|-- overview
|
|-- whats-new
|
|-- core
| |-- core-beans
| |-- core-aop
|-- testing
|
|-- data-access
|
|-- web
| |-- web-mvc
| |-- web-view
|-- integration
|
|-- appendix
|-- appx-spring-tld
|-- appx-spring-form-tld
```
Supersedes and closes#641
Issue: SPR-12309
All HttpMessageConverters should support StreamingHttpOutputMessage.
Specifically, the BufferedImageHttpMessageConverter and
FormHttpMessageConverter should do so.
Issue: SPR-12715
This commit adds the following to gradle.properties in order to execute
the Gradle daemon on JDK 9, since Gradle's DaemonParameters
automatically sets the MaxPermSize JVM argument, which is no longer
supported on JDK 9.
org.gradle.jvmargs=-XX:MaxMetaspaceSize=1024m -Xmx1024m
Issue: SPR-12549
Previously, adding `@EnableAsync` on a blank application would lead to an
info message stating that `ProxyAsyncConfiguration` is not eligible for
getting processed by all BeanPostProcessors. Concretely, this is ok as
such internal configuration is not meant to be a target of such post
processing.
Revisit the condition for non infrastructure bean only. Add the
infrastructure role to a set of internal configuration, including the
`ProxyAsyncConfiguration`.
Issue: SPR-12761
Support the creation and registration of message listener containers in
a lazy manner, that is after the container initialization has completed.
Such support brought an interesting brainstorming of the thread safety
if JmsListenerEndpointRegistrar and JmsListenerEndpointRegistry so those
have also been revisited as part of this commit.
Issue: SPR-12774
This commit simplifies the implementations of loadBeanDefinitions() in
GenericGroovyXmlContextLoader and GenericGroovyXmlWebContextLoader.
Due to the recent bug fix for GroovyBeanDefinitionReader regarding full
support for XML config files, these Groovy context loaders can now
simply use a GroovyBeanDefinitionReader instead of a
GroovyBeanDefinitionReader plus an XmlBeanDefinitionReader.
Issue: SPR-12769
Prior to this commit, the GroovyBeanDefinitionReader claimed (via its
Javadoc) that it fully supported XML configuration files in addition to
its Groovy DSL; however, this was unfortunately inaccurate since XML
validation was disabled by default which led to certain features of XML
configuration not working. For example, it was impossible to define a
<qualifier> in an XML config file without specifying the 'type'
attribute (which has a default value defined in the spring-beans XSD).
This commit fixes this issue by ensuring that bean definitions in XML
resources are loaded with a "standard" XmlBeanDefinitionReader that is
created with default settings (i.e., with XML validation enabled). With
regard to backwards compatibility, bean definitions defined using the
Groovy DSL are still loaded with an XmlBeanDefinitionReader that has
XML validation disabled by default which is necessary for proper
parsing of the Groovy DSL.
Issue: SPR-12769
Prior to this commit, it was impossible to use all features of XML
configuration (e.g., the <qualifier> tag) in web-based integration
tests (loaded using @WebAppConfiguration, @ContextConfiguration, etc.)
if the Groovy library was on the classpath. The reason is that the
GroovyBeanDefinitionReader used internally by
GenericGroovyXmlWebContextLoader disables XML validation for its
internal XmlBeanDefinitionReader, and this prevents some XML
configuration features from working properly. For example, the default
value for the 'type' attribute (defined in the spring-beans XSD) of the
<qualifier> tag gets ignored, resulting in an exception when the
application context is loaded.
This commit addresses this issue by refactoring the implementation of
loadBeanDefinitions() in GenericGroovyXmlWebContextLoader to use an
XmlBeanDefinitionReader or GroovyBeanDefinitionReader depending on the
file extension of the resource location from which bean definitions
should be loaded. This aligns the functionality of
GenericGroovyXmlWebContextLoader with the existing functionality of
GenericGroovyXmlContextLoader.
Issue: SPR-12768
Prior to this commit, the implementation of equals() in EncodedResource
was based solely on the resource and encoding. Thus, if a Charset were
specified instead of an encoding, invocations of equals() would not
work as expected.
This commit addresses this issue by including the charset in the
implementation of equals() and introducing corresponding tests in a new
EncodedResourceTests class. Furthermore, this commit makes
EncodedResource immutable and updates all Javadoc to reflect support
for the encoding and charset properties.
Issue: SPR-12767
To eliminate code duplication, ScriptStatementFailedException and
ScriptUtils now delegate to a new buildErrorMessage() utility method.
Issue: SPR-12752
This commit ensures Resources have consistent, non-empty, meaningful
implementations for getDescription(), thus ensuring that calls to
toString() (e.g., in log statements) no longer return an empty String.
This commit also polishes the Javadoc for various Resource
implementations.
Prior to this change, location checks for serving resources would append
`/` to the location path it didn't already have one.
This commit makes sure not to append a `/` if the provided location is
actually a file.
Issue: SPR-12747
Reduce logging level when no target annotation is found a on bean. For
consistency, update ScheduledAnnotationBeanPostProcessor and
JmsListenerAnnotationBeanPostProcessor that define the same log
statement.
Issue: SPR-12574
Animal Sniffer 1.11 fails against XStream 1.4.8 due to classes with 1.8 bytecode level.
Animal Sniffer 1.14 will finally include ASM 5.0.3 for proper 1.8 bytecode support.
Add StreamConverter to provide full support for converting
java.util.stream.Stream instances to and from collections or arrays.
Also attempt to convert the element type if necessary.
StreamConverter is registered by default in the DefaultConversionService
as long as Java8 is available.
Issue: SPR-12175
When a bean is retrieved via JNDI using Java config, we apply the same
inferred more for destruction callbacks as for any other bean. If an
object from the JNDI tree has a `close` or `shutdown` method, the
context calls it when it shutdowns.
Unfortunately, we have no way to know that the bean was retrieved via
JNDI and that its lifecycle is managed outside the application.
The documentation has been updated to reflect that problem explicitly.
Issue: SPR-12551
If an `@EventListener` annotated method returns a Collection or an Array,
each individual items are now published as an event instead of publishing
one event with said collection.
Issue: SPR-12733
JmsInvokerClientInterceptor defines a receiveTimeout field but does not
handle such timeout. This commit adds an additional callback that throws
an RemoteTimeoutException instead.
Sub-classes can override the onReceiveTimeout to throw a different
exception or return a fallback RemoteInvocationResult.
Issue: SPR-12731
With this commit, WebUtils.isValidOrigin() logs an error message instead
of throwing an IllegalArgumentException when Origin header value is
invalid (for example when it does not contain the scheme).
Issue: SPR-12697
Deprecated CommonsPoolTargetSource (supporting commons pool 1.5+) in
favor of CommonsPool2TargetSource with a similar contract.
Commons Pool 2.x uses object equality while Commons Pool 1.x used
identity equality. This clearly means that Commons Pool 2 behaves
differently if several instances having the same identity according to
their `Object#equals(Object)` method are managed in the same pool. To
provide a smooth upgrade, a backward-compatible pool is created by
default; use `setUseObjectEquality(boolean)` if you need the standard
Commons Pool 2.x behavior.
Issue: SPR-12532
Previously, the `@Order` annotation was managed in an inconsistent way
when placed at the implementation level. For simple beans, it was
discovered properly but wasn't for beans requiring a proxy.
OrderComparator.SourceProvider now explicitly allows to return several
order sources; the default implementation returns not only the factory
method (if any) but also the target class if it happens to be different
from the class of the bean.
Issue: SPR-12636
This commit adds support for a same origin check that compares
Origin header to Host header. It also changes the default setting
from all origins allowed to only same origin allowed.
Issues: SPR-12697, SPR-12685
- Added assertions for pre-conditions on method arguments for all
public utility methods.
- Introduced additional tests in TestPropertySourceUtilsTests to verify
the new pre-conditions.
- Introduced INLINED_PROPERTIES_PROPERTY_SOURCE_NAME constant for the
name of the MapPropertySource created from inlined properties; the
name therefore no longer contains the inlined properties, but the
original values of the inlined properties can now be logged at debug
level.
- Simplified tests in InlinedPropertiesTestPropertySourceTests.
Issue: SPR-12721
Spring Framework 4.1 introduced support for @TestPropertySource;
however, the utilities used to parse inlined properties and add test
property sources to the environment are currently private which
prevents reuse by third-party frameworks like Spring Boot.
This commit addresses this issue by making such utilities public.
- TestPropertySourceUtils is now a public class.
- Various utility methods in TestPropertySourceUtils have been made
public.
- addResourcePropertySourcesToEnvironment() has been renamed to
addPropertiesFilesToEnvironment().
- extractEnvironmentProperties() has been renamed to
convertInlinedPropertiesToMap().
- All public methods in TestPropertySourceUtils are now fully
documented.
Issue: SPR-12721
The initial implementation for adding inlined properties configured via
@TestPropertySource to the context's environment did not preserve the
order in which the properties were physically declared. This makes
@TestPropertySource a poor testing facility for mimicking the
production environment's configuration if the property source mechanism
used in production preserves ordering of property names -- which is the
case for YAML-based property sources used in Spring Boot, Spring Yarn,
etc.
This commit addresses this issue by ensuring that the ordering of
inlined properties declared via @TestPropertySource is preserved.
Specifically, the original functionality has been refactored. extracted
from AbstractContextLoader, and moved to TestPropertySourceUtils where
it may later be made public for general purpose use in other frameworks.
Issue: SPR-12710
Before this change the WebSocketTransportHandler passed
Collections.emptyMap as attributes to the HandshakeHandler because
it didn't matter what attributes the underlying WebSocketSession has
since it is wrapped by the SockJsSession and that's what exposed for
use everywhere.
This change has the WebSocketTransportHandler passing the attributes
from the SockJsSession instead since it's more accurate for the
underlying WebSocketSession to have access to the same map instance
and it allows the HandshakeHandler to change the attributes even if
it doesn't need to do that today.
Issue: SPR-12716
This commit introduces further regression tests to ensure proper parsing
of inlined properties configured via @TestPropertySource. Specifically,
these additional tests ensure that we do not introduce a bug like the
one raised in Spring Boot issue #1110 [0].
[0] https://github.com/spring-projects/spring-boot/issues/1110
Issue: SPR-12710
Previously, the exception-handler attribute was not taken care of when
task:annotation-driven is used in AspectJ mode. This commit provides the
expected behavior.
Issue: SPR-12619
Jasper Reports’ transitive dependency on spring-context (via
castor-xml which is a new dependency in 6.0.3) was being mapped by
Gradle to a dependency on the spring-context project. For reasons that
I do not fully understand this was causing -source and -javadoc jars
to be added to the project's compile classpath which is used by the
Animal Sniffer Ant task. When the task runs these jars do not exist
which causes it to fail. This commit fixes the problem by adding an
exclusion of org.springframework:spring-context to the Jasper Reports
dependencies in spring-context-support and spring-webmvc.
Previously, only indexed access for collections were supported. When
attempting to access the element of an array that had not the requested
size, the call would fail with an IndexOutOfBoundException
This commit harmonize the binding support so that the array is updated
according to the requested index if necessary.
Issue: SPR-12706
Previously, a cache decorated with TransactionAwareCacheDecorator would
clear the cache immediately, even when a transaction is running. This
commit updates the decorator to synchronize to the afterCommit phase for
the clear operation as well.
Issue: SPR-12653
Update the application event listener infrastructure to support events
that are processed according to a transactional phase.
Introduce EventListenerFactory that can be implemented to provide support
for additional event listener types. TransactionalEventListener is a new
annotation that can be used in lieu of the regular EventListener. Its
related factory implementation is registered in the context automatically
via @EnableTransactionManagement or <tx:annotation-driven/>
By default, a TransactionalEventListener is invoked when the transaction
has completed successfully (i.e. AFTER_COMMIT). Additional phases are
provided to handle BEFORE_COMMIT and AFTER_ROLLBACK events.
If no transaction is running, such listener is not invoked at all unless
the `fallbackExecution` flag has been explicitly set.
Issue: SPR-12080
Add support for annotation-based event listeners. Enabled automatically
when using Java configuration or can be enabled explicitly via the
regular <context:annotation-driven/> XML element. Detect methods of
managed beans annotated with @EventListener, either directly or through
a meta-annotation.
Annotated methods must define the event type they listen to as a single
parameter argument. Events are automatically filtered out according to
the method signature. When additional runtime filtering is required, one
can specify the `condition` attribute of the annotation that defines a
SpEL expression that should match to actually invoke the method for a
particular event. The root context exposes the actual `event`
(`#root.event`) and method arguments (`#root.args`). Individual method
arguments are also exposed via either the `a` or `p` alias (`#a0` refers
to the first method argument). Finally, methods arguments are exposed via
their names if that information can be discovered.
Events can be either an ApplicationEvent or any arbitrary payload. Such
payload is wrapped automatically in a PayloadApplicationEvent and managed
explicitly internally. As a result, users can now publish and listen
for arbitrary objects.
If an annotated method has a return value, an non null result is actually
published as a new event, something like:
@EventListener
public FooEvent handle(BarEvent event) { ... }
Events can be handled in an aynchronous manner by adding `@Async` to the
event method declaration and enabling such infrastructure. Events can
also be ordered by adding an `@Order` annotation to the event method.
Issue: SPR-11622
Update the event publishing infrastructure to support generics-based
events, that is support ApplicationListener implementations that define
a generic event, something like:
public class MyListener
implements ApplicationListener<GenericEvent<String>> { ... }
This listener should only receive events that are matching the generic
signature, for instance:
public class StringEvent extends GenericEvent<String> { ... }
Note that because of type erasure, publishing an event that defines the
generic type at the instance level will not work. In other words,
publishing "new GenericEvent<String>" will not work as expected as type
erasure will define it as GenericEvent<?>.
To support this feature, use the new GenericApplicationListener that
supersedes SmartApplicationListener to handle generics-based even types via
`supportsEventType` that takes a ResolvableType instance instead of the
simple Class of the event. ApplicationEventMulticaster has an additional
method to multicast an event based on the event and its ResolvableType.
Issue: SPR-8201
Before this change, detection of X-Forwarded-* headers was only built
into ServletUriComponentsBuilder.
This change adds a new method for creating a UriComponentsBuilder from
an existing HttpRequest. This is equivalent to the fromUri method +
X-Forwarded-* header values.
This commit introduces the following changes:
- Requests without Origin header are not rejected anymore
- Disable Iframe when allowedOrigins is not empty and not equals to *
- The Iframe is not cached anymore in order to have a reliable origin check
- allowedOrigins must not be null or empty
- allowedOrigins format is now validated (should be * or start by http(s)://)
Issue: SPR-12660
Update documentation to explicitly mention that the cache interceptor
must be fully initialized to provide the expected behavior and therefore
initialization code should not rely on this feature, i;e. typically in
PostConstruct callback.
Since the Transactional infrastructure has the exact same infrastructure,
update that section of the doc as well.
Issue: SPR-12700
Previously, one could only set the list of bean names to exclude from
auto-detection and there was no way to add additional bean names.
MBeanExporter now exposes a addExcludedBean method that can be invoked
during the initialization phase to add bean names to ignore.
Issue: SPR-12686
Prior to this change, the `ResourceUrlProvider.getForLookupPath` method
would try to match handlers using the keySet order in the
handlerMappings Map. In case of several matches, the handler used for
the return value could vary, since the registration order in the
handlerMappings can't be guaranteed in the configuration.
This commit now collects all matching handlers and sort them using a
`PatternComparator`, in order to try each handler from the most specific
mapping to the least.
Issue: SPR-12647
This commit also adds a modules(Module...) method in addition to
modules(List<Module> modules) in order to be consistent with other
parts of the API.
Issue: SPR-12634
Before this change, the maxRequestSize property was used (incorrectly)
to limit both the size of the request and response. The change:
- removes maxRequestSize and therefore no longer places limits on the
size of the request thus matching to AbstractBufferingClientHttpRequest
which is the base class for other buffering client implementations.
- adds maxResponseSize property required to create Netty's
HttpObjectAggregator for aggregating responses.
Issue: SPR-12623
Prior to this change when adding subscriptions
DefaultSubscriptionRegistry (incorrectly) made a copy of the given map
for its "access" cache rather than for its "update" cache.
Issue: SPR-12665
Provide an additional hook-point for YamlProcessor subclasses willing to
change how the Yaml instance is configured. Also expose the default
StrictMapAppenderConstructor so that they can compose a custom instance
with it.
Issue: SPR-12671
This commit adds ResponseBodyEmitter and SseEmitter (and also
ResponseEntity<ResponseBodyEmitter> and ResponseEntity<SseEmitter>) as
new return value types supported on @RequestMapping controller methods.
See Javadoc on respective types for more details.
Issue: SPR-12212
Move MethodCacheKey and related classes to the expression package so that
other parts of the framework can benefit ot it.
CacheExpressionEvaluator is a base class that can be used to cache SpEL
expressions based on its annotation source (i.e. method). Sub-classing
that base class provides a simple to use API to retrieve Expression
instances efficiently.
Issue: SPR-12622
Prior to this commit, the `ContentCachingRequestWrapper` class would
cache the response content only if the reponse would be consumed using
its InputStream. In case of a Form request, Spring MVC consumes the
response using the `getParameter*` Servlet API methods. This causes the
cached content to never be written.
This commit makes the `ContentCachingResponseWrapper` write the request
body to the cache buffer by using the `getParameter*` API, thus avoiding
those issues.
Issue: SPR-7913
Modules (well-known or user provided) registration is now performed
first in order to allow their configuration to be customized by more
specific ones like custom serializers or deserializers.
Issue: SPR-12634
Spring Framework 4.0 introduced support for using test-related
annotations as meta-annotations in the Spring TestContext Framework
(TCF) in order to create custom composed annotations within a test
suite; however, the detection of default @Configuration classes in test
classes was not updated to search for @Configuration declared as a
meta-annotation. Specifically, AnnotationConfigContextLoaderUtils
invokes Class.isAnnotated() which only searches for annotations
declared directly on the class in question.
This commit addresses this issue by refactoring the
isDefaultConfigurationClassCandidate() method in
AnnotationConfigContextLoaderUtils so that it uses
AnnotationUtils.findAnnotation() instead of Class.isAnnotated() for
detecting the presence of the @Configuration annotation, either
directly or as a meta-annotation.
Issue: SPR-12659
Various parts of the reference manual as well as the Javadoc for
AnnotationConfigContextLoaderUtils improperly refer to "static inner
classes" even though this terminology does not exist in Java. The Java
Language Specification explicitly refers to such classes as "static
nested classes." An "inner class" must be non-static by definition.
Prior to this change, the ResourceUrlProvider would listen to
ContextRefreshedEvents and autodetect resource handlers each time. This
can cause issues when multiple contexts are involved and the last one
has no resource handler, thus clearing the previously detected ones.
This commit disables resource handlers auto-detection once some have
been detected with a refreshed context.
Issue: SPR-12592
Prior to this change, location paths used for resource handling would
not allow "non-cleaned, relative paths" such as
`file://home/user/static/../static/`. When checking if the resolved
resource's path starts with the location path, a mismatch would happen
when comparing for example:
* the location `file://home/user/static/../static/`
* and the resource `file://home/user/static/resource.txt`
This commit cleans the location path before comparing it to the resource
path.
Issue: SPR-12624
This commit allows the use of "protcol relative URLs" (i.e. URLs without
scheme, starting with `//`), often used to serve resources automatically
from https or http with third party domains.
This syntax is allowed by RFC 3986.
Issue: SPR-12632
This commit fixes the default value for the contextRelative attribute of
a RedirectView, when this view is registered via a
RedirectViewController in XML. The value is set to true.
Note that the default value for this is correctly documented in
spring-mvc-4.1.xsd. Also, the documentation and implementation for its
javadoc counterpart also enforces true as a default value.
Issue: SPR-12607
A logical follow-up on commit 43d937, this change also removes (or
rather deprecates for now) writePrelude that is only of concern to
streaming SockJS session implementations.
Issue: SPR-12427
This change removes the need for the isStreaming field from the base
class AbstractHttpSockJsSession. This field was used to account for
differences between polling vs streaming SockJS sessions without having
to expose to sub-classes private fields that are otherwise protected
from concurrent access by the base class. The change manages to delegate
to sub-classes without providing direct access to protected fields.
Issue: SPR-12427
This commit overhauls several of the tests that interact with an
MBeanServer with the goal of increasing the reliability of these tests.
- MBeanClientInterceptorTests now uses JUnit "assumptions" instead of
preemptively returning from test methods, thus allowing such methods
to be properly marked as "ignored" instead of "passed".
- MBeanClientInterceptorTests now uses JUnit's support for expected
exceptions where appropriate.
- MBeanClientInterceptorTests and RemoteMBeanClientInterceptorTests now
use Spring's SocketUtils to find an available TCP port when starting
an MBeanServer instead of aborting the tests when the default JMX
port is not available.
Issue: SPR-12601
Commit 65d163e changed the textual message of an exception thrown by
ScheduledAnnotationBeanPostProcessor.afterSingletonsInstantiated(), and
this in turn caused the withAmbiguousTaskSchedulers_andSingleTask()
method in EnableSchedulingTests to start failing (albeit only during
'Performance' builds).
This commit updates the assertion to match the current implementation of
ScheduledAnnotationBeanPostProcessor.
In order to allow DefaultActiveProfilesResolver to be reused (e.g., via
extension or delegation), the check which asserts that the 'resolver'
attribute of @ActiveProfiles is not set to a customer resolver class
has been removed.
Issue: SPR-12611
JUnit 4.9 introduced a regression in BlockJUnit4ClassRunner.runChild()
such that exceptions thrown from methodBlock() cause the current test
execution to abort immediately. As a result, the failing test method is
unrooted, and subsequent test methods are never invoked. Furthermore,
RunListeners registered with JUnit are not properly notified.
In conjunction with SPR-11908, SpringJUnit4ClassRunner was updated to
use the aforementioned changes to BlockJUnit4ClassRunner.runChild().
Consequently, SpringJUnit4ClassRunner now suffers from the same
regression.
This commit addresses this issue by ensuring that any exceptions thrown
during the invocation of methodBlock() are properly wrapped in a JUnit
Fail Statement.
Issue: SPR-12613
- Copyright end date is now dynamic, based on the current year.
- Added missing spaces in front of web link to ASL 2.0 license file.
- Changed @since tag to 4.2.
Prior to this commit, HTTP responses without body (response status 204
or 304, Content-Length: 0) were handled properly by RestTemplates. But
some other cases were not properly managed, throwing exceptions for
valid HTTP responses.
This commit better handles HTTP responses, using a response wrapper that
can tell if a response:
* has no message body (HTTP status 1XX, 204, 304 or Content-Length:0)
* has an empty message body
This covers rfc7230 Section 3.3.3.
Issue: SPR-8016
Prior to this change, the ShallowEtagHeaderFilter would use a
ResizableByteArrayOutputStream to internally write data and calculate
the ETag. While that implementation is faster than the regular
ByteArrayOutputStream (since it has a better strategy for growing the
internal buffer), a lot of buffer copying/writing still happens.
This change adds a new FastByteArrayOutputStream implementation that
internally uses a LinkedList<Byte[]> to store the content. So when
writing bytes to that OutputStream implementation, new byte[] are
added to the list when the previous ones are full. This saves most
of the instantiating/copying operations.
Note that new methods were added in DigestUtils to allow usage of
Streams instead of byte[], which is more efficient in our case.
Fixes#653
Issue: SPR-12081
The test was verifying that when a DISCONNECT frame is sent to the
broker, there will be no further messages on the clientOutboundChannel.
This is generally true, however in some cases when the broker receives
a DISCONNECT it may close its connection fast enough (before we do) in
which case we send an ERROR message downstream to ensure the WebSocket
side is cleaned up. Either way the downstream should be idempotent
with regards to cleaning up sessions.
This change designates Jetty SockJS integration tests to run as part of
the "performance", but not the main "publication", CI build due to
recurring low-level failures suspected to be Jetty issues, e.g.
"java.io.IOException: Cannot append to finished buffer" or
"java.io.IOException: Out of order Continuation frame encountered".
The tests will still run at once a day with the performance build but
should not fail the main build with false negatives. Also note that
an Undertow variant of the exact same tests, which hasn't been failing,
will continue to run as part of the main build.
Update HttpComponents wrapper to merge local customizations with the
default of the current HttpClient instead of overriding everything.
This is available as from HttpComponents 4.4. that exposes the default
request config from the client via the Configurable interface. If the
client does not implement such interface, the previous behaviour is
applied
Issue: SPR-12583
Fix a regression introduced by 961574bd17 that prevents a proper lookup
of the default transaction manager by name as the absence of a qualifier
is represented by an empty string (passing the faulty null check).
Issue: SPR-12577
Prior to this commit, some requests would be wrongly mapped to "/" when:
* requests ends with "//" such as "/foo/bar//"
* the DispatcherServlet is mapped as the default ("/")
* the app container sanitizes the servletPath
In those cases, the path extraction algorithm was wrongly guessing the
path of the current request.
This commit detects if the app container sanitized the servletPath for
the current request. If so, it uses a sanitized version of the
requestUri to extract the path information.
Issue: SPR-12372
// Special case: it returned "this" and the return type of the method
// is type-compatible. Note that we can't help if the target sets
@@ -241,7 +247,7 @@ final class JdkDynamicAopProxy implements AopProxy, InvocationHandler, Serializa
* or a dynamic proxy wrapping a JdkDynamicAopProxy instance.
*/
@Override
publicbooleanequals(Objectother){
publicbooleanequals(@NullableObjectother){
if(other==this){
returntrue;
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Spring Buildmaster