This breaks the package dependency cycle between web.server/web.method and makes ServerErrorException more generally applicable. Includes deprecation of the plain reason constructor variant, in favor of providing a Method or MethodParameter context (which MatrixVariableMethodArgumentResolver does now).
Prior to this commit it was impossible to have an individual
constructor argument in a @Nested (i.e., inner) test class injected via
@Autowired, @Qualifier, or @Value.
This is due to a bug in javac on JDK versions prior to 9, whereby
annotation lookups performed directly via the
java.lang.reflect.Parameter API fail for inner class constructors.
Specifically, the parameter annotations array in the compiled byte code
for the user's test class excludes an entry for the implicit enclosing
instance parameter for an inner class constructor.
This commit introduces a workaround in ParameterAutowireUtils for this
off-by-one error by transparently looking up annotations on the
preceding Parameter object (i.e., index - 1). In addition, this commit
relies on the change recently introduced in MethodParameter in order to
compensate for the same JDK bug (see SPR-16652).
Issue: SPR-16653
In my opinion, we should parse ":{x}" style parameter as "x" is parameter using "NamedParameterUtils.parseSqlStatement",
so the condition "j - i > 2" is the correct condition, not "j - i > 3", because if "i" is the index of
":" in ":{x}", and "j" is the index of "}" in ":{x}", "j - i == 3" is true.
Also add a test case for SPR-16663.
This commit introduces tests for looking up annotations on parameters
in constructors for nested and inner classes via Spring's
MethodParameter abstraction.
The test for an inner class is currently disabled since it fails on
JDK 8. See JIRA issue for details.
Issue: SPR-16652
Consistently return "*/*" if no media types were requested rather than
an empty list. Existing code has to check for both in any case to see
if nothing was requested.
Issue: SPR-16624
Consistently return "*/*" if no media types were requested rather than
an empty list. Existing code has to check for both in any case to see
if nothing was requested.
Issue: SPR-16624
This commit introduces @Nested tests to verify support for constructor
injection when using the SpringExtension.
One of the tests is disabled on Java 8 due to a bug in javac that was
first fixed in JDK 9.
See https://github.com/junit-team/junit5/issues/1345 for details.
The prevailing current wisdom is to use the default constructor for
secure and let it pick the best algorithm for the OS.
On Java 8 (Oracle), Linux this results in "NativePRNG" which uses
/dev/random (potentially blocking) for the initial seed, and
/dev/urandom (non-blocking) for subsequent calls to nextInt.
Issue: SPR-16635
Rather than create a new EvaluationContext instance per evaluation, we
now create a statically shared instance, without the root object in it,
and re-use it for all evalutations.
The web.server package is quite low-level and should not depend on web.bind in order to avoid a dependency cycle. Extracting the introspection of the ResponseStatus annotation into a WebFlux-level subclass resolves the cycle.
Issue: SPR-16567
Undertow does not provide a way to check if data is available to read
but instead we have to try to read and see if any data is returned.
This makes it impossible to implement checkOnDataAvailable without
trying to read and that can lead to infinite recursion like this:
...
UndertowServerHttpRequest$RequestBodyPublisher.checkOnDataAvailable(UndertowServerHttpRequest.java:156)
AbstractListenerReadPublisher.changeToDemandState(AbstractListenerReadPublisher.java:177)
AbstractListenerReadPublisher.access$900(AbstractListenerReadPublisher.java:47)
AbstractListenerReadPublisher$State$4.onDataAvailable(AbstractListenerReadPublisher.java:319)
AbstractListenerReadPublisher.onDataAvailable(AbstractListenerReadPublisher.java:85)
UndertowServerHttpRequest$RequestBodyPublisher.checkOnDataAvailable(UndertowServerHttpRequest.java:156)
This commit prevent the call to checkOnDataAvailable() when switching
states from READING->DEMAND which implies we exited the readAndPublish
loop because there was no more data to read.
Issue: SPR-16545
This commit allows several DeferredImportSelector instances to be
grouped and managed in a centralized fashion. This typically allows
different instances to provide a consistent ordered set of imports to
apply.
Issue: SPR-16589
This commit picks up where SPR-14498 left off by adding support for an
explicit target type when using JsonPath to perform an assertion against
the response content using a Hamcrest Matcher.
Specifically, there is a new overloaded value(Matcher<T>, Class<T>)
method in JsonPathResultMatchers for use with Hamcrest matchers where
the target type (i.e., Class<T>) can be specified.
Issue: SPR-16587
With this change the code generation for method and property
references is modified to include branching logic in the
case of null safe dereferencing (?.). This is complicated
by the possible usage of primitives on the left hand side
of the dereference. To cope with this case primitives are
promoted to boxed types when this situation occurs enabling
null to be passed as a possible result.
Issue: SPR-16489
This commit restructures the existing content to separate out Overview
content into its own section, and also introduces more formal structure
where reference type content can be expanded over time.
Issue: SPR-16547
Prior to this commit, the `HttpEntityMethodProcessor` would check HTTP
conditions on non-safe requests (i.e. not GET/HEAD). This would prevent
Controllers from returning `ResponseEntity` containing response headers
with updated values of `"Last-Modified"` or `ETag` once the resource has
been updated.
This commit avoids those checks for non GET/HEAD requests - this code
can still be leveraged from Controllers themselves using
`ServletWebRequest::checkNotModified` methods.
Issue: SPR-15780
After send error, ignore calls to complete or completeWithError by the
application in the same thread (e.g. try-catch block), to avoid a
competing with an error callback from servlet container during which
the same action is taken.
Issue: SPR-16548
When checking whether there is still request body the first method
that should be checked is ServletInputStream.isReady() and then
ServletInputStream.isFinished(). ServletInputStream.isReady() is the active
method whereas the ServletInputStream.isFinished() is not.
It is important to call ServletInputStream.isReady() because if it returns
false it will schedule a dispatch and if the request body is already read it will
send onAllDataRead event.
Issue: SPR-16521
Includes related polishing in core.metadata and datasource.embedded and a revision of the corresponding database definitions in sql-error-codes.
Issue: SPR-16558
This commit makes sure that no `StringIndexOutOfBoundsException` is
thrown when `getForRequestUrl` is called with a URL that's shorter than
the expected context path.
Issue: SPR-16526
Jackson2Tokenizer now also wraps JsonProcessingException's on
endOfInput(), as it also does in tokenize(DataBuffer). This ensures
treating those errors as 400 vs 500.
Issue: SPR-16521
When read returns -1, we know we've reached the end of input. Instead
of waiting for the onAllDataRead container callback, this commit
proactively calls onAllDataRead.
Issue: SPR-16521
Make the protected fields in AbstractJackson2Encoder private plus
minor refactoring to the way streaming separators are applied.
The current (5.0.3) behavior is to always use '\n', but in 5.0.4 the
newly supported "application/stream+x-jackson-smile" needs to be
excluded from that. For now, separator determination remains private
in the abstract base class, but current behavior remains which is to
apply '\n' by default.
Issue: SPR-15424
This commit adds an Asciidoc anchor to the section on different injection
styles to be able to link to the discussion as official recommendation.
Closes gh-1681
As of 4.3.13 MappingJackson2MessageConverter uses the MethodParameter
hint to obtain generic type information but it needs to be careful, and
nest one level, if the target parameter type has a Message wrapper.
Issue: SPR-16486
This commit introduces DataBuffer.asInputStream(boolean), that can
release the underlying buffer when the stream is closed.
Furthermore, this commit adds additional javadoc.
Issue: SPR-16444
After this commit the use of interval in tests is combined with
take(n).onBackpressureBuffer(n) to ensure emissions don't fail if the
fixed rate is exceeded (e.g. on slow CI server).
Tests that verify N number of items followed by verifyOnComplete()
should set the number of emissions to N.
Tests that verify N number of items followed by thenCancel() should
set the number of buffered to an arbitrary number greater than N.
This commit updates HttpWebHandlerAdapter and
ResponseStatusExceptionHandler in order to specify the method/uri in the
logged message.
It also logs a WARN message for bad request (400) HTTP responses in
order to get some logs when an exception is thrown due to client error
(unable to deserialize request body for example).
Issue: SPR-16447
Previously MockHttpServletRequestBuilder calculated the pathInfo from the
provided URL without decoding the value. This meant that the pathInfo
incorrectly included URL encoded values.
Now MockHttpServletRequestBuilder properly decodes the pathInfo.
Fixes: SPR-16453
MockHttpServletResponse no longer calls flushBuffer on calls to
getContentAsByteArray and getContentAsString. The flushing doesn't
actually do anything useful but does commit the response leading to
unexpected side effects.
Issue: SPR-16430
This commit adds these 2 Vary headers in addition to the existing
Origin one to avoid caching of Access-Control-Request-Method and
Access-Control-Request-Headers headers which can be an issue
when allowed methods or headers are unbounded and only the
requested method or headers are returned in the response.
Issue: SPR-16413
From:
Thymeleaf
Groovy Markup
FreeMarker
JSP & JSTL
Script Views
XML
Tiles
XSLT
PDF, Excel
RSS, Atom
Jackson
To:
Thymeleaf
FreeMarker
Groovy Markup
Script views
JSP & JSTL
Tiles
RSS, Atom
PDF, Excel
Jackson
XML
XSLT
Also move View Technologies after MVC Config to align order with
WebFlux config.
Issue: SPR-16393
The commit brings following changes:
- Move getDecodableMimeTypes() to AbstractJackson2Decoder
- Move getEncodableMimeTypes() to AbstractJackson2Encoder
- Add support for application/stream+x-jackson-smile
- Avoid streaming line separator when Smile encoder is used
- Use double null token in Jackson2Tokenizer to identify documents
Issue: SPR-16151
The resolved URI instance is also being cached now. This should not make a difference in a real Servlet environment but does affect tests which assumed they could modify an HttpServletRequest path behind a pre-created ServletServerHttpRequest instance. Our WebSocket test base class has been revised accordingly, re-creating the ServletServerHttpRequest in such a case.
Issue: SPR-16414
This commit makes sure there is no custom Content-Disposition header
before setting one automatically.
This commit also adds a headers(Consumer<HttpHeaders>) method, so that
one can user the nicer methods of HttpHeaders, as opposed to basic
strings.
Issue: SPR-16376
Since Java7 HttpURLConnection offers setFixedLengthStreamingMode method with long parameter which should be prefered over version with int argument, therefore casting ContentLength to int is no longer needed. Moreover it makes impossible to stream payload larger than Integer.MAX_VALUE
Now that SPR-16307 makes it possible to write a part with a Publisher
we need to ensure we get the filename correctly when writing with
Publisher<Resource>.
Issue: SPR-16376
After this commit DefaultUserDestinationResolves no longer looks at
whether AntPathMatcher is configured with "." as separator and rather
expects to be explicitly told whether to keep the leading slash in
translated destinations which actually depends on what the message
broker supports (e.g. RabbitMQ "/", Artemis ".") or how it is
configured (simple broker could be either way).
There is also a minor improvement in SimpMessagingTemplate to ensure
user destinations are correctly formed based on what the
DefaultUserDestinationResolver expects. When using "." as separtor it
allows sending messages to "queue.q1" rather than "/queue.q1".
Issue: SPR-16275
The previous fix #09f1f7 did not actually address the issue but only
moved it further down, so instead of the subscribe(), it was consuming
it inside the MultipartHttpMessageWriter#write method which returned
this.body.then(), and then again for the actual request body writing.
In this commit MultipartHttpMessageWriter#write returns Mono.empty()
since we don't actually want to write the part content from there, but
only want to access it as soon as it is availabele, for writing to
the request body.
Issue: SPR-16402
This commit checks the Etag/LastModified headers on the incoming
request, and sets a 304 Not Modified status with no body when they
match, by delegating to ServerWebExchange.checkNotModified.
Issue: SPR-16348
This commit separates the creation of a response so that it is executed
after the synchronized block inside which requests need to be matched
and validated (for order and count).
This allows a ResponseCreator to be slow or block if it has to.
Issue: SPR-16319
We cover this more succinctly from other places, e.g. in Model Methods
by referring to the Javadoc of Contentions, or pointing to the
RequestToViewNameTranslator.
As of EclipseLink 2.4.0 - Juno this is not sufficient to log
SQL parameter binding. Additionally,
eclipselink.logging.parameters must be enabled.
Issue: SPR-16383
After this commit, AbstractSockJsService uses the configured allowed
origins when generating the CorsConfiguration instead of "*".
As a consequence, forbidden origin requests still result in a 403
response but now with no CORS headers in order to improve consistency
between the status code and the headers.
Issue: SPR-16304
Use DataBufferUtils.compose instead of writeAggregator to combine
multiple data buffers into one, as the write aggregator would not work
when the initial data buffer did not have enough capacity to contain
all subsequent buffers.
Removed writeAggregator, as it is no longer needed.
Issue: SPR-16365
Added a utility method that composes data buffers into a single buffer.
Depending on the `DataBuffer` implementation, the returned buffer may be
a single buffer containing all data of the provided buffers, or it may
be a true composite that contains references to the buffers.
Issue: SPR-16365
The match/matches methods of UriTemplate use a regex with (.*) in place
of URI variables, which work fine except in the end where such a
pattern can match greedily more than one segment.
This commit updates the regex to use ([^/]*) instead since URI
variables are only meant to be used within a single path segment.
Issue: SPR-16169
Clarify what PathPatternParser is used for which is CORS checks in the
very least. Some sub-classes will also use it for request mapping but
not all (e.g. RouterFunctionMapping). Hence the need to be more
explicit.
@EnableWebFlux bootstraps both annotated controllers and functional
endpoints, so we need to be more explicit about which parts of the
configuration apply to which.
Issue: SPR-16360
This commit polishes SPR-16022 fix in order to handle correctly
the case when primary and default constructors are the same when
a secondary constructor is defined.
Issue: SPR-16289
As a consequence of dropping CompositeByteBuf (see prior commit),
DataBuffers fluxes that are aggregated with Flux.reduce(BiFunction) are
now required to be released, as the composite no longer holds a
reference to subsequent data buffers.
For this purpose, DataBufferUtils now has a writeAggregator that can be
used with Flux.reduce, and that released the subsequent buffers
properly.
Issue: SPR-16351
Prior to this commit, NettyDataBuffer had a optimization in
write(ByteBuf...), where it used a CompositeByteBuf to hold the original
and the parameter buffer.
Unfortunately, this procedure has nasty consequences when splicing
buffers (see https://stackoverflow.com/a/48111196/839733).
As of this commit, NettyDataBuffer stopped using CompositeByteBuf, and
simply does ByteBuf.write().
Issue: SPR-16351
Optimize same origin check when the request is an instance of
ServletServerHttpRequest and when there is no forwarded headers.
This commit also optimizes the getPort methods and ForwardedHeaderFilter
forwarded headers checks.
Issue: SPR-16262
This commit refines forwarded protocol support in order to support
proxies that only set "X-Forwarded-Proto" header and not
"X-Forwarded-Port" by performing a reset of the port in such case.
"Forwarded" header support has been updated accordingly since it
also supports similar use case, as described in SPR-15504.
Issue: SPR-16262
Since type erasure can be fixed only when using
ParameterizedTypeReference based Java methods, RestOperations and
WebFlux API documentation should be updated to specify which extensions
are subject to type erasure, and which are not.
Issue: SPR-16273
This allows us to confirm 0.7.3 fixes and run tests against the latest
ahead of an upgrade to Reactor Netty 0.8 snapshots.
The fix for #231 and #240 are confirmed but unfortunately test case for
This commit moves the ResolvableType field from HttpEntity to
PublisherEntity, a new entity type defined in MultipartBodyBuilder.
With this change, the scope of the ResolvableType is limited to
multipart-related code, instead of becoming part of the complete
HttpEntity hierarchy.
Issue: SPR-16307
This commit adds new header assertions for `WebTestClient`.
`doesNotExist` tests that a given header is not present:
.expectHeader().doesNotExist("Cache-Control");
`contentTypeCompatibleWith` tests for MediaType compatibility:
.expectHeader().contentTypeCompatibleWith("text/*");
Issue: SPR-16285
This commit adds a ResolvableType field to HttpEntity, in order to
support Publishers as multipart data. Without the type, the
MultipartHttpMessageWriter does not know which delegate writer to use to
write the part.
Issue: SPR-16307
This commit allows CorsConfiguration#combine()
to differentiate permit default values set by
CorsConfiguration#applyPermitDefaultValues()
from values configured explicitly by the user.
Those permit default values will be overridden
by any user-provided ones while user-provided values
will be combined in an additive way, including
when "*" is specified.
Documentation has been improved accordingly.
Issue: SPR-15772
With this commit, the default content-type defined by the
view (usually "text/html;charset=UTF-8" defined in AbstractView)
is used if any, when none is defined in the response headers.
Issue: SPR-16247
This commit removes the mention that Spring Boot 2.0 includes
Jackson Kotlin module since it is not the case as of M7, and
add a note about using bean validation annotations with Kotlin.
If the response is set and we can't change the status through
ServerHttpResponse any more, allow the error signal to propagate and
let the individual server adapters handle it. Ultimately that should
result in closing the connection.
On Servlet containers, we check one last time if the response is
committed (we may not have filled the buffer). If not then save
the exception as a request attribute, dispatch, and re-throw it on the
container thread.
On Undertow access the connection and close it.
On Netty just let the error through to Reactor Netty.
Issue: SPR-16051
Provide a fully mutable HttpHeaders to ClientHttpRequestInterceptors
of a RestTemplate when headers are set using HttpEntity. This avoids
UnsupportedOperationException if both HttpEntity and
ClientHttpRequestInterceptor add values for the same HTTP header.
Issue: SPR-15066
As of Gradle Kotlin plugin 1.1.60,
project.sourceSets.main.kotlin.srcDirs contains
Java source directories in addition to Kotlin
ones. This commit filter out Java sources to
retain only Kotlin ones.
Issue: SPR-16268
This commit fixes a bug where an IllegalStateException was
thrown if the minPort and maxPort values supplied to
SocketUtils.findAvailableTcpPort(int, int) were identical.
From #9a894a we began using the content-type from the ResponseEntity
but cross-checking it still against the requested content type.
Arguably there isn't any purpose in cross-checking. The only possible
outcomes are: a) it's compatible or b) it's not, which would result in
406 (NOT_ACCEPTABLE). As we've been given explicitly the media type to
use, it makes little sense to send 406, ignoring the wish to use that
content type.
Issue: SPR-16251
The request URI returned from HttpServerRequest.uri() typically
contains contains an absolute path but could also contain an
absolute URI. This commit adds handling for the latter, effectively
taking only the absolute path portion.
Issue: SPR-16243
apiVersion and languageVersion options are set to 1.1
on production code in order to avoid incompatibilities
with Kotlin 1.1 based projects or libraries.
Issue: SPR-16239
ResponseStatusExceptionHandler lets the error through if it can't
change the status while HttpWebHandlerAdapter logs a more helpful
message (including status code) but without a full stack trace.
Issue: SPR-16231
- Add "Processing" section (also replaces Advanced Customizations)
- Add information on out-of-the-box behavior
- Add more deails on @CrossOririn default configuratio
- Add cross-references between Spring MVC and WebFlux
- Polish
1. setComplete checks the isCommitted flag to avoid an unnecessary
debug message. This method is meant to be safe to call many times.
2. setStatusCode lowers log message to TRACE, since the return value
communicates the outcome it's arguably much less critical.
3. Add comment and test case for ResponseStatusExceptionHandler.
A ResponseStatusException is clearly meant to be handled by this
handler so don't let it pass through even if the respones is
committed.
Issue: SPR-16231
Before this commit, the return value from write was interpreted as the
data being fully written and ready to be released via releaseData().
This is not true for WebSocketSession implementations where a true
return value simply means the message was sent with the full payload
but releas is not appropriate until a send confirmation.
Technically not an issue since WebSocketSession's extending this do
not use pooled buffers. Nevertheless this commit refines the semantics
of write, removes the releaseData() method, and makes sub-classes
responsible for releasing the buffer when fully written (and they
know best when that is). As a bonus currentData is now private.
Issue: SPR-16207
After this commit, Tomcat and Undertow WebSocketSession imlpementations
start out in suspended mode and wait for demand.
The JettyWebSocketSession is capable of suspending but it doesn't seem
to work if invoked before any messages are received. That may become an
issue if there is a case where no demand appears long enough for more
messages to accumulate than we can hold.
UnderowServerHttpRequest would ideally also start in suspended mode but
that also doesn't work. It is not an issue in this case since we can
ignore the read notifications.
Servlet API requires a proactive check before it calls you back so
there is no need to suspend.
Issue: SPR-16207
This commit turns suspendReading() into a readingPaused() notification
that is invoked after a succession of reads stops because there is no
more demand. Sub-classes can use this notification to suspend, if that
applies to them.
Most importantly the notification is guaranteed not to overlap with
checkOnDataAvailable() which means that suspend does not need to be
atomic and guarded against resume. The two can and do compete all the
time when reading ends with no demand, and a request for demand arrives
concurrently.
Issue: SPR-16207
Access-Control-Allow-Credentials CORS header, used to
allow cookies with CORS requests, is not set to true
anymore by default when enabling CORS with
@CrossOrigin or global CORS configuration in order to
provide a more secured default CORS configuration.
The related allowCredentials property now requires to
be set to true explicitly in order to support cookies
with CORS requests.
Issue: SPR-16130
Transition from DEMAND->NO_DEMAND:
Two concurrent threads enter DEMAND.request and DEMAND.onDataAvailable.
And DEMAND.onDataAvailable finishes before DEMAND.request to be able to
update the demand field then a request for reading will be lost.
Transition from READING->NO_DEMAND:
readAndPublish() returns false because there is no demand but before
switching the states READING.request is invoked again a request for
reading will be lost.
Changing READING->DEMAND/NO_DEMAND is made conditional so that the
operations will be executed only if changing states succeeds.
When in READING state detect completion before each next item in order
to exit sooner, if completed.
Issue: SPR-16207
- Ensure completion signal (normal/exception) will be delivered to
the subscriber when transition from UNSUBSCRIBED->COMPLETED
- According to the specification "Publisher.subscribe MUST call onSubscribe
on the provided Subscriber prior to any other signals to that Subscriber" so
ensure onComplete/onError signals will be called AFTER onSubscribe signal.
Issue: SPR-16207
This commit changes the implementation of the PathPattern
extractPathWithinPattern method that used an old AntPathMatcher
derivative to a new version that integrates more closely with
PathContainer.
It also introduces consistency in a couple of areas. The javadoc
is updated to specify this but basically:
- the response from the extra method will have all leading
and trailing separators removed.
- the response will have multiple adjacent separators within the
reponse reduced to just one. (For example response would be
aaa/bb/cc and not aaa///bbb//cc)
If your response would start or finish with multiple separators, they
are all removed.
Issue: SPR-16120
- When there is no demand for reading, the implementation
should suspend reading otherwise useless events will be
send by Undertow to the registered read listener.
- There is not need to wait for an event for reading/writing after calling
resumeReads/resumeWrites
This commit adds
AbstractMessageReaderArgumentResolver#readBody and
AbstractMessageWriterResultHandler#writeBody variants
which allow to pass the actual MethodParameter in order
to perform proper annotation-based hint resolution with
nested generics, for example with HttpEntity.
Issue: SPR-16098
Autowiring implicitely Kotlin primary constructors
when there are secondary constructors has side effects
on ConstructorResolver. It seems reasonable to
require explicit @Autowired annotation in such case.
With this commit, implicit autowiring of Kotlin
primary constructors is only performed when there
is a primary constructor defined alone or with
a default constructor (define explicitly or
generated via the kotlin-noarg compiler plugin
or via optional constructor parameters with default
values).
Issue: SPR-16022
The EXTENSION_RECEIVER parameter of Kotlin's extension
methods appear as normal method parameters to Java and
thus require a name. The synthetic name "$receiver" is
used here, as it is not a valid Kotlin identifier,
but valid in Java.
Issue: SPR-16119
This commit uses the existing CompositeByteBuf if present, as opposed
to creating a new composite for every call to
NettyDataBuffer.write(ByteBuf...)
Issue: SPR-16180
Practically no changes to RxNetty for a year and efforts underway to
rebuild 0.6.x based on a current Reactor Netty base.
Aside from the extra time to run integration tests having two
Netty-based servers can also cause false alarms such as ByteBuf leaks
related to RxNetty.
Also remove ErrorDeferredResultProcessingInterceptor which was meant
to be package private to begin with as its peer
ErrorCallableProcessingInterceptor (also removed).
Create the buffer with at least the original sql length to avoid
multiple re-allocations
Add a fast path if the original sql doesn't contain any parameters
Includes fixes for invalid exception declarations in Mockito-based unit tests. Also includes FreeMarker 2.3.27, Commons Pool 2.4.3, JSON-P 1.1.2.
Issue: SPR-16157
This commit introduces a new AbstractReactiveWebInitializer in
spring-web that relies on WebHttpHandlerBuilder to detect request
processing infrastructure beans from an ApplicationContext.
This eliminates the need to create a DispatcherHandler, since it is
expected to be a Spring bean, and as a result the initializers in
spring-webflux have been deprecated.
Issue: SPR-16144
The RFCs around basic authentication don't explicitly disallow empty
usernames. On the other hand usernames containing colons are, as colons
are used to separate the username from the password.
SimpMessageTypeMessageCondition was lenient in matching the message
type, essentially matching on any non-null message type with an exact
match given a preference only in comparing mulitple matches.
This commit modifies matching logic to look for an exact match.
Issue: SPR-16109
FromHttpMessageWriter and MultipartHttpMessageWriter both support
MultiValueMap except the former supports String values only. This
presents an issue since either full generic type information must be
provided, which is cumbersome on the client side, or if left out there
is no good way to order the writers to make a proper decision.
This commit:
- refines the canWrite behavior of to not a
accept MultiValueMap without proper generic information unless the
MediaType is explicitly set providing a strong hint.
- modifies MultipartHttpMessageWriter to be configured with a
FormHttpMessageWriter so it can write both plan and multipart data with
the ability to properly differentiate based on actual map values.
Issue: SPR-16131
This avoids "IllegalStateException: Expectations already declared" when
a MockRestServiceServer is used after one request throws an exception.
Issues: SPR-16132
This commit changes the way Undertow's PooledByteBuffers are dealt with.
Previously, these buffers where closed as soon as all data was read. As
of this commit, the UndertowServerHttpRequest returns PooledDataBuffers
from getBody(), so that the buffers are released when release() is
called.
The "Build from Source" wiki page now consolidates build-related information
and is independent from "Release" information. The former is broadly of interest
to any contributor. The later is of interest to committers.
This commit decouples ExchangeResult from knowledge about
WiretapClientHttpRequest/Response both of which are now private to
WiretapConnector.
ExchangeResult takes ClientHttpRequest/Response instead along with
promises for the serialized request and response content in the form
of MonoProcessor<byte[]>.
This sets up the possibility for an ExchangeResult to be created
outside and independent of WebTestClient, should we decide to make its
constructor public.
Issue: SPR-16101
The main way CONTRIBUTING will be viewed is on Github and the output
is just not good enough to justify using asciidoctor vs md/txt as
the recommended on the Github help page for contributing guidelines.
For example it was attractive to use a TOC and that works on Github
but doesn't look good. In the end it's a very short TOC and
maintaining manually is easy enough and it's easier to control the
look.
The guidelines were originally created several years ago. This commit
does not fundamentally change anything but rather make the guidance
more compact.
The commit consolidates into into CONTRIBUTING.adoc information from
CONTRIBUTING-DOCUMENTATION.adoc and also the wiki page "The Lifecycle
of an Issue".
Directly inlined hasLength implementations for proper nullability detection in IntelliJ, assuming a hasText checked value is never null afterwards. Since the JVM is going to do this at runtime anyway, this is effectively equivalent but more indicative for source code introspection algorithms.
Issue: SPR-15540
A new HTTP/2 support section has been added in the Spring MVC
documentation. Also, a dedicated wiki page is created for specific
container support information.
Issue: SPR-15821
This commit exposes the ClientRequest's URL and HttpMethod fields via a
setter, so that they can be changed more easily in a request that was
created via ClientRequest.from(ClientRequest).
Issue: SPR-16093
This commit introduces various improvements in DataBuffer:
- DataBuffer now exposes its read and write position, as well as its
capacity and writable byte count.
- Added DataBuffer.asByteBuffer(int, int)
- DataBufferUtils.read now reads directly into a DataBuffer, rather than
copying a ByteBuffer into a DataBuffer
- TomcatHttpHandler now reads directly into a DataBuffer
Issues: SPR-16068 SPR-16070
MockMvc now properly detects the presence of an AsyncContext and
re-uses the response instance used to start it.
This commit also includes a minor fix in
ResponseBodyEmitterReturnValueHandler to ensure it does not disable
ETag related content buffering for reactive return values that do not
result in streaming (e.g. single value or collections).
Issue: SPR-16067
Includes redeclaration of CodecConfigurer.DefaultCodecs without concrete Jackson decoder/encoder references in order to avoid hard Jackson dependency.
Issue: SPR-16064
Before this commit, when adding filters to a builder obtained via
`WebClient.mutate()`, the filters were added both to the original client
as well as the mutated builder. This commit fixes that.
Issue: SPR-16059
Prior to this commit, the `ResourceWebHandler` would itself handle the
response with an HTTP 404 in many cases, including a missing static
resource.
This does not give a chance to `WebExceptionHandler` instances to handle
that error and, for example, display an error page.
See spring-projects/spring-boot#8625
Issue: SPR-16023
Prior to this commit, the Resource `HandlerMapping` configured by
`@EnableSpringMvc` would be set up with only one custom
`HandlerInterceptor` (the one exposing the `ResourceUrlProvider` for
resolving URLs of static resources).
This behavior is not consistent with the rest of the default
configuration which leverages the interceptors configured against the
interceptor registry (with possible user-provided ones).
This change allows to register interceptors against resource handling;
this can be useful for metrics purposes, as in
spring-projects/spring-boot#10335.
Issue: SPR-16034
The Javadoc on tag classes now has all the information including a
list of all tags at the package level, HTML tables listing tag
attributes in each tag class, and class level description that is
as good or in many cases better than what was in the reference.
Issue: SPR-16045
1. Move schemas to local appendix within each top-level section.
2. Link to Javadoc for JSP tags
3. Purge Class Spring usage information
Issue: SPR-16045
The WebTestClient now takes advantage of the support for decoding
response to Void.class in WebClient so that applications can use
expectBody(Void.class) to the same effect as using
response.bodyToMono(Void.class) as documneted on WebClient#exchange.
The top-level, no-arg returnResult method (added very recently) has been
retracted, since the use of returnResult at that level, i.e. without
consuming the response content, should be used mainly for streaming.
It shouldn't be used for "no content" scenarios.
Documentation and Javadoc have been udpated accordingly.
Use the ClientResponse methods bodyToMono and bodyToFlux rather than
passing in a BodyExtractor so that WebTestclient now also benefits from
the recently improved handling of Void.class.
Before this commit those were burried in the Appendix where few would
guess to look. Previously that information was at the top, so it makes
sense to point to the Github wiki from the index HTML page.
Also a general update of the index page. Since we have recently revised
the overview, we can simply point to it and keep it shorter.
The section listing now includes more details per section.
Before this commit WebClient documentation was also included from the
Integration section where the RestTemplate is documented. That is
convenient but results in duplicate content under different URLs.
This commit removes the include from the Integration section and leaves
Concrete server and client, reactive request and response
implementations should not have to be accessed outside their package.
They could be seen as private to their HttpHandler adapters and
ClientHttpConnector's respectively.
The one exception, WebSocket upgrades in spring-webflux, is an internal
framework use case, accommodated via downcast + accessors in the
abstract base classes.
Prior to this commit, the `WebClient` always throws a `ClassCastException`
when an error occurs in `bodyToMono(ParameterizedTypeReference)``, and
not the expected exception, as set up by `onStatus`
Issue: SPR-16025
Extract WebClient content into a separate file that is now included
both in the WebFlux and in the Integration sections.
This allows having RestTemplate and WebClient documented in one place
under Integration while also keeping the same included in the WebFlux
section too.
Prior to this commit, asking for a `Void` type using any of the
`ClientResponse#bodyTo*` methods would immediately return an empty
`Publisher` without consuming the response body.
Not doing so can lead to HTTP connection pool inconsistencies and/or
memory leaks, since:
* a connection that still has a response body being written to it cannot
be properly recycled in the connection pool
* incoming `DataBuffer` might not be released
This commit detects when `Void` types are asked as body types and in
those cases does the following:
1. Subscribe to the response body `Publisher` to allow the connection to
be returned to the connection pool
2. `cancel()` the body `Publisher` if the response body is not empty; in
that case, we choose to close the connection vs. consume the whole
response body
Those changes imply that `ClientHttpResponse` and other related
contracts don't need a `close()` method anymore.
Issue: SPR-16018
Includes unified detection of Kotlin's optional parameters in MethodParameter.isOptional(), reduces BeanUtils.findPrimaryConstructor to Kotlin semantics (for reuse in AutowiredAnnotationBeanPostProcessor), and finally introduces a common KotlinDetector delegate with an isKotlinType(Class) check.
Issue: SPR-15877
Issue: SPR-16020
Prior to this issue, SPR-15920 added this new `close()` method which was
supposed to be called to clean resources after response processing.
This commit changes the meaning of that method: calling `close()` will
close the underlying HTTP connection. This has to be called if the
response body is not consumed by the application, since at that point
the underlying connection might be in an inconsistent state if shared in
a connection pool.
Issue: SPR-15993
Now that WebSessionStore is in charge of expiration checks on retrieve
it makes sense to also update the lastAccessTime on retrieve at the
same time, saving the need to call it after a retrieve.
Issue: SPR-15963
It is no longer adequate to list supported arguments and return values
-- between Web MVC and WebFlux, directly on the annotation.
Instead we have tables in the respective chapters in the reference with
cross references to each other.
Issue: SPR-15149
This commit makes Reactor Netty `WebClient` instances
support zero-copy requests by implementing `ZeroCopyHttpOutputMessage`.
The implementation leverages the optimized `sendFile` mechanism if
available.
This commit moves WebFluxUriComponentsBuilder.fromServerRequest to the
ServerRequest interface itself.
Consequently, the WebFluxUriComponentsBuilder is removes itself, as it
contained no other methods.
Issue: SPR-15953
The typical way to load DispatcherHandler is to use
WebHttpHandlerBuilder#applicationContext which also detecs filters,
exception handlers, as well as other beans that are injected into every
ServerWebExchange -- custom session manager, localecontext resolver,
codecs for form data, multipart data, etc
WebHttpHandlerBuilder is the preferred and way so removing the ones on
DispatcherHandler. They could always be added back later.
This commit introduces a visitor for router functions
(RouterFunctions.Visitor), allowing to iterate over all the components
that make up a router function.
This commit also introduces a ToStringVisitor, which creates a nicely
formatted string for use with toString().
Issue: SPR-15711, SPR-15711
Also, ChannelRegistration.setInterceptors is deprecated now: in favor of a fluently named interceptors(...) method which is documented to add the given interceptors to the channel's current list.
Issue: SPR-15962
Issue: SPR-15976
This commit makes sure that any custom MessageConverter set in a
JmsTemplate used by a JmsMessagingTemplate is reused as the payload
converter of the message.
Issue: SPR-15965
This commit introduces the WebFluxUriComponentsBuilder, with a single
method that creates a UriComponentsBuilder for a ServerRequest. More
methods to be added by @rstoyanchev.
Issue: SPR-15953
This commit introduces a methodName() method to the ServerRequest,
returning the String name of the method. This method is useful for
non-standard HTTP methods.
This commit introduces the following changes.
1) It adds a new Spring @NonNull annotation which allows to apply
@NonNullApi semantic on a specific element, like @Nullable does.
Combined with @Nullable, it allows partial null-safety support when
package granularity is too broad.
2) @Nullable and @NonNull can apply to ElementType.TYPE_USE in order
to be used on generic type arguments (SPR-15942).
3) Annotations does not apply to ElementType.TYPE_PARAMETER anymore
since it is not supported yet (applicability for such use case is
controversial and need to be discussed).
4) @NonNullApi does not apply to ElementType.FIELD anymore since in a
lot of use cases (private, protected) it is not part for the public API
+ its usage should remain opt-in. A dedicated @NonNullFields annotation
has been added in order to set fields default to non-nullable.
5) Updated Javadoc and reference documentation.
Issue: SPR-15756
When writing Publisher<Publisher<T>>, a flush operation is performed onComplete
for every Publisher. If the flush operation is not able to be performed immediately
it will be retried before starting to process data provided by the next Publisher.
For the last Publisher the implementation needs to ensure that the flush will
be performed only then whole operation will complete.
Issue: SPR-15949
This commit introduces a ForwardedHeaderFilter for WebFlux, similar to
the existing Servlet version. As part of this the
DefaultServerHttpRequestBuilder had to be changed to no longer use
delegation, but instead use a deep copy at the point of mutate().
Otherwise, headers could not be removed.
Issue: SPR-15954
This commit fixes a typo in the `DefaultWebClient` implementation.
Instead of forwarding resolved `WebClientException` instances as error
signals, the `bodyToMono(ParameterizedTypeReference)` variant would just
forward those exceptions as `onNext` signals.
Issue: SPR-15946
Prior to that commit, the `ResponseSpec` `WebClient` would process error
responses (4xx, 5xx HTTP status) and transform those into error signals
with a `WebClientResponseException`. But this would only work if the
HTTP response would have a non-empty response body.
An empty error response would not send an error signal and only
translate in an `onComplete` signal.
This commit fixes this behavior and makes sure that this error signal is
sent in all cases.
Issue: SPR-15946
Now that https://github.com/reactor/reactor-netty/issues/138 is solved,
this commit removes the temporary workaround introduced in SPR-15784
but leaves the general mechanism for detecting empty responses.
The high level matchStarting API was removed a few commits ago.
This change tidies up by removing the supporting infrastructure
for that from the PathElements.
Prior to this commit, various dependencies in the spring-test module
pulled in commons-logging as a transitive dependency. Consequently,
the presence of commons-logging in the generated Eclipse classpath
overrode the intended use of the spring-jcl module causing JUL to be
used instead of log4j for tests executed within Eclipse, thereby
ignoring the configuration in src/test/resources/log4j2-test.xml.
This commit addresses this issue by excluding commons-logging in
spring-test.gradle for all Selenium dependencies.
Issue: SPR-15930
InMemoryWebSessionStore is very closely associated to DefaultWebSession
passing it to it several fields and functions. Now that the store also
creates the session, it makes sense to bring the latter in as an inner,
nested class.
Issue: SPR-15875, 15876
DefaultWebSessionManager no longer requires the WebSessionStore
to use DefaultWebSession.
Removed explicit start() in save(). This seemed unnecessary since at
that point isStarted is guaranteed to return true. The status can
be updated through the copy constructor.
DefaultWebSessionTests added.
Issue: SPR-15875
- Add WebSessionStore.createWebSession.
- Remove remove WebSessionStore.changeSessionId
- Add WebSessionStore updateLastAccessTime which allows updating the
WebSession lastAccessTime without exposing a method on WebSession in
an implementation independent way.
- Remove WebSessionStore.storeSession. This method is not necessary
since the WebSession that is returned allows saving the WebSession.
Additionally, it is error prone since the wrong type might be passed
into it.
Issue: SPR-15875, 15876
Add missing DefaultWebSessionManagerTests .block(). Previously
session.save() was invoked, but we did not ensure it was completed.
This commit makes it block on session.save()
Fix existingSessionIsExpired. This test is actually broken and is
testing a new session is created because the session id returned
by the idResolver does not match the existing WebSession.
This commit ensures that the id of the WebSession found by idResolver
matches the existing WebSession.
DefaultWebSessionManagerTests use Mockito. To ensure we test with
independence from InMemoryWebSessionStore we use Mockito for the
DefaultWebessionManager collaborators.
Add test for response.setComplete(). We want to ensure that when the
response is completed, it saves the WebSession and writes it to the
response using idResolver
Use constant for default header name and make getHeaderName private.
Also switch HeaderWebSessionIdResolverTests to unit tests rather than
testing with DefaultWebSessionManager.
Issue: SPR-15917
Before this commit, there was no way to signal the HTTP client that we
were done consuming the response. Without that, the underlying client
library cannot know when it is safe to release the associated resources
(e.g. the HTTP connection).
This commit adds new `close()` methods on both `ClientHttpResponse`
and `ClientResponse`. This methods is non-blocking and its behavior
depends on the library, its configuration, HTTP version, etc.
At the `WebClient` level, `close()` is called automatically if we
consume the response body through the `ResponseSpec` or the
`ClientResponse` itself.
Note that it is *required* to call `close()` manually otherwise; not
doing so might create resource leaks or connection issues.
Issue: SPR-15920
This commit introduces a test that demonstrates that custom JUnit 4
rules can be @Autowired into a test instance but that they will not be
applied by JUnit since JUnit only ever sees such fields as null and
therefore ignores them.
Issue: SPR-15927
This commit moves `encodeUrl` and `registerUrlEncoder` from
ServerHttpResponse to ServerWebExchange.
It also renames `encodeUrl` to `transformUrl` and `registerUrlEncoder`
to `addUrlTransformer` to make it clearer that these methods do not
perform actual URL encodings (i.e. they do not replaceinvalid
characters).
The `add` prefix (instead of `register`) makes it clearer that each
function is added in addition to the previous one.
Issue: SPR-15924
Introduces HeaderSessionIdResolver, which reads session ids from a session header and generates a session response header when new session are created.
Related issue: SPR-15917
`ReactorClientHttpConnector` provides an adapter layer to `WebClient`
for using Reactor-Netty's `HttpClient`.
This commit enables HTTP compression support by default for this client
Connector.
Another constructor is still available for providing a custom
`HttpOptions` configuration.
Issue: SPR-15908
Prior to this commit, HTTP Range requests were only supported by the
ResourceHttpRequestHandler when serving static resources.
This commit improves the `HttpEntityMethodProcessor` and
the `RequestResponseBodyMethodProcessor`. They now extract
`ResourceRegion`s from the `Resource` instance returned by the
Controller and let the Resource-related message converters
handle the writing of the resource (including 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-15789, SPR-13834
This change allows much more usable TOC for the reactive
stack and will make WebFlux documentation easier to
contribute thanks to a clearer split between both stacks.
Issue: SPR-15149
The upgrade to Gradle 4.0 broke the custom Eclipse support in the
Spring Framework build.
This commit includes the following changes which re-enable support for
Eclipse in the build.
- Switched to ProjectDependency(String) constructor
- Updated regular expression that matches against project output
dependencies to include more than one subdirectory between "build"
and "main"|"test".
Issue: SPR-15862
This commit adds support for autowired constructor parameters
on Kotlin classes with optional parameters. If some constructor
parameters are not available, optional parameter default values
will be used instead. Both explicit @Autowired annotated constructor
and implicit single constructor automatically autowired are supported.
Issue: SPR-15847
This commit reinstates the Spring Framework BOM, which was previously
empty because of a previous change in 41cbc4670f.
This change also removes the JSR305 dependency from the BOM, which does
not belong here since it is not an artifact produced by Spring.
Issue: SPR-15885
This commit ensures that only the HTML version of the reference
documentation is rendered for SNAPSHOT builds. This speeds up
significatly the build.
Issue: SPR-15885
As of Gradle 4.0, project SourceSets can have multiple output
directories (one per programming language).
This commit fixes warnings that are logged when a single output dir
is considered by tasks.
Issue: SPR-15885
This commit applies the Dependency Management Plugin to modules that
require it; right now Spring Framework is importing BOMs for Netty and
Reactor dependencies only.
Instead of applying those BOMs to all modules, they're applied only
where they're needed.
Issue: SPR-15885
The main `build.gradle` file contains now only the common build
infrastructure; all module-specific build configurations have
been moved to their own build file.
Issue: SPR-15885
This commit merges back the "spring-beans-groovy" module into the main
"spring-beans" one. The build is configured so:
* Java and Groovy sources are jointly compiled
* Kotlin sources are compiled after
With this change, the `MergePlugin` is not used anymore in the project
build and therefore is removed.
The `DetectSplitPackagesPlugin` wasn't applied so it's been removed as
well.
Issue: SPR-15885
With this change, each subproject can configure its
build in a dedicated file like:
```
spring-core/spring-core.gradle
spring-web/spring-web.gradle
```
Issue: SPR-15885
This commit configures Gradle build scans for the Spring Framework
build. Scans aren't performed for every build but can be enabled
with the following:
```
./gradlew build --scan
```
Issue: SPR-15885
Includes general streamlining of dependency declarations with reduced version variables, direct use of EclipseLink 2.7 and its implicit JPA 2.2 dependency in spring-orm, mixed use of Hibernate 5.2.10 and 5.1.10 for integration tests, as well as an upgrade to Jetty 9.4.7 RC0 and a downgrade to Groovy 2.4.12 (since Groovy 2.5 won't be final in time for Spring Framework 5.0).
Issue: SPR-15879
Issue: SPR-15880
Bean-derived null values may still get passed into bean properties and injection points but only if those are declared as non-required. Note that getBean will never return null; a manual bean.equals(null) / "null".equals(bean.toString()) check identifies expected null values now. This will only ever happen with custom FactoryBeans or factory methods returning null - and since all common cases are handled by autowiring or bean property values in bean definitions, there should be no need to ever manually check for such a null value received from getBean.
Issue: SPR-15829
Refer to both Servlet and reactive stacks in web.adoc
Move web-integration.adoc to the very end
Link in web-flux-functional.adoc
Insert "Spring Web MVC" or "Servlet" prefix in chapter titles
Issue: SPR-15149
This commit restores and existing redirectedUrl and forwardedUrl
methods (simple String comparison) and creates separate
redirectedUrlTemplate and forwardedUrlTemplate methods that expand
and also encode before comparing.
Issue: SPR-15834
This commit revises the implementation of the SpringExtension to use
the getRequired*() methods in the ExtensionContext which are now built
into JUnit Jupiter thanks to inspiration from the initial "convenience"
methods implemented here.
The PathPattern compareTo method is now consistent with equals when
two patterns are of the same specificity but otherwise different.
Separately PathPattern now exposes a Comparator by specificity that
offers the current functionality of compareTo. This can be used for
actual sorting where we only care about specificity.
Consistent behavior with matches(PathContainer), the two had slightly
different logic for handling of empty paths.
Make matchAndExtract independantly usable without the need to call
matches(PathContainer) first. Essentially no longer raising ISE if the
pattern doesn't match but simply returning null.
Rename getPathRemaining to matchStartOfPath since the method does
match and to be more clear about what the method and the return value
intuitively follows.
Remove matchStart which matches the start of the pattern (rather than
the start of the path). It is a use case that does not come up in
request mapping.
This commit changes the WebClient so that it now throws a
`WebClientResponseException` for `ResponseSpec.bodyTo`. This newly
introduces exception contains the status code, headers, and body of the
response message.
As a consequence of the above, we had to change `onStatus` so that the
`exceptionFunction` now returns a `Mono<Throwable>` rather than a
`Throwable`, which it was before. The Mono allows for asynchronous
operations, such as reading the contents of the body.
Issue: SPR-15824
Remove the separator constructor argument (but preserve internal
functionality) now that PathPatternParser is more explicitly purposed
for URL paths and in any case the use of an alternate separator would
also requires a similar input option on the PathContainer parsing side.
Re-arrange the checks so that if there is no form parameter, then
immediately and unconditionally delegate to super.getParameterValues().
Or reversely if there is no super.getParameterValues() then return the
form parameter.
So the only remaining case is when combining values present in both.
In that case we'll take both only if a queryString exists.
One extra fix is to not even wrap the request if we did not parse any
form parameters at all which can happen with HttpHiddenMethodFilter.
Issue: SPR-15828, 15835
Removed superfluous `fromServerSentEvent` variants from `BodyInserters`,
as their functionality can also be obtained by passing a stream of
strings or POJOs (to be encoded as JSON) to
`fromPublisher(Publisher, Class)}`, and specifying a `text/event-stream`
Content-Type.
Issue: SPR-15826
This commit also removes WebFlux non-extension functions in favor of
regular Kotlin extensions leveraging ParameterizedTypeReference parameter.
Issue: SPR-15818
This commit changes the usage of two separate attributes (username and
password) into one: a single `Credentials` object.
Additionally, the attributes key under which the credentials are stored
is changed to be specific to Basic Authentication, in order to allow for
other sorts of authentication later.
Issue: SPR-15764
This commit changes adds overloaded `ParameterizedTypeReference `
variants to body-related methods in `ServerRequest` and
`ServerResponse`.
It also adds a single PTR variant to ClientRequest, which was missing
before.
Issue: SPR-15817
This commit changes all consumers of CodecConfigurer to consume a `List`
of HttpMessageReaders or HttpMessageWriters instead of consuming the
Server- or ClientCodecConfigurer directly.
Issue: SPR-15816
By using function literals with receiver, we can avoid requiring
lambda parameters for a shorter and nicer syntax. Based on a
proposal from Joseph Taylor.
Issue: SPR-15815
When the input stream is a JSON array the tokenizer skips over the
start and end array tokens in order to decode into an array of
top-level objects. However in this mode it also skips over nested
start and end array tokens which prevents proper parsing of JSR-310
dates (represented with an array syntax) as well as any fields that
are collections.
Issue: SPR-15803
The method was orginally added under SPR-14547 but the example in it
was probably intended for use with Content-Disposition server response
header (file dowonload) and not for a Content-Disposition header
within the body of a multipart request.
In a Spring application a multipart request is typically serialized
by the FormHttpMessageConverter and hence the Content-Disposition is
not explicitly set by the application.
Issue: SPR-15205
This commit parses the "Host" HTTP request header as an
`InetSocketAddress`, while supporting IPv6 addresses like `[::1]`.
This host string contains `:` chars even though it has no port
information.
Issue: SPR-15799
StandardMultipartHttpServletRequest now properly decodes RFC-5987
encoded filenames (i.e. filename*) by delegating to ContentDisposition
and also support RFC-2047 syntax through javax.mail MimeUtility.
Issue: SPR-15205
This commit updates BeanUtils class in order to add Kotlin optional
parameters with default values support to the immutable data classes
support introduced by SPR-15199.
Issue: SPR-15673
Prior to this commit, the host+port information of the incoming request
where taken from the remoteAddress, which is actually the socket address
of the HTTP client (i.e. not the server).
This commit resolves this information from the "Host" HTTP request
header, if available, or the actual local address of the channel if no
header is available.
Issue: SPR-15084
Add an option for ForwardedHeaderFilter to only process the
HttpServletRequest. This means that HttpServletResponse.sendRedirect will
only work when the application is conifgured to use relative redirects
using Servlet Container specific setup.
Issue: SPR-15717
This commit ensure that null-safety is consistent between
getters and setters in order to be able to provide beans
with properties with a common type when type safety is
taken in account like with Kotlin.
It also add a few missing property level @Nullable
annotations.
Issue: SPR-15792
Since there is no reason for an exchange to ever complete without a
ClientResponse I've added a switchIfEmpty check at the WebClient level.
Also, temporarily a second check closer to the problem in the
ReactorClientHttpConnector suggesting a workaround and providing a
reference to the Reactor Netty issue #138.
Issue: SPR-15784
Collapse the base interface VersionPathStrategy into its extension
VersionStrategy and then turn the prefix nad fliename based
implementations into abstract base classes (vs delegate strategies).
It is simpler to have one VersionStrategy hierarchy vs that plus a
separate VersionPathStrategy as a delegate. In practice each
VersionStrategy is suited to be prefix or filename based. Also none
of our code cares about the distinction between those two interfaces.
Since `PathPattern.combine` now returns another `PathPattern` instance
(it was previously returning a String instance), we can now safely
remove the parser instance included in `PatternsRequestCondition`.
Issue: SPR-15663
Currently ResourceEncoder and ResourceRegionEncoder use DataBufferUtils
to read resource with an AsynchronousFileChannel if it is a file or
otherwise fallback on getting the channel from the resource.
The same is now required in other places where a Resource needs to be
read and is also generally useful.
Issue: SPR-15773
Use copy constructor to refresh a session with lastAccessTime and a
save function referencing the current exchange. As a result both fields
are now final and ConfigurableWebSession is no longer needed.
This commit changes the write methods to return `Flux<DataBuffer>`
instead of `Mono<Void>`, giving access to the original buffers,
so that they can decided whether the buffers need to be closed or not.
Issue: SPR-15726
This commit adds an overloaded write method to `DataBufferUtils`. There
are three parameter variants: `OutputStream`, `WritableByteChannel`, and
`AsynchronousFileChannel`.
Issue: SPR-15726
This commit introduces overloaded variants of `bodytoMono`,
`bodyToFlux`, `toEntity`, and `toEntityList` that take a
`ParameterizedTypeReference`. It also adds similar methods to
`WebClient.ResponseSpec`.
Issue: SPR-15725
This binary format more efficient than JSON should be useful for server
to server communication, for example in micro-services use cases.
Issue: SPR-15424
Avoid re-using the WriteBarrier as the Subscription to both the
completionSubscriber and the writeSubscriber.
Instead DownstreamBridge is now called WriteCompletionBarrier and is
both a Subscriber and Subscription, i.e. handles all signals to and
from the completion Subscriber.
This frees the request method implementation in WriteBarrier to assume
it can only be called by the writeSubscriber and hence it's safe to
pass on request signals to the write source outside the synchronized
block.
This commit introduces a boolean `readOnly` flag in `HttpHeaders`,
which is used to check if creating a new `HttpHeaders` instance is
necessary in `readOnlyHttpHeaders`.
As a follow-up of the ApplicationContext Kotlin extensions, close to
the Kotlin functional WebFlux DSL and partially inspired of the
Groovy/Scala bean configuration DSL, this commit introduces a
lightweight Kotlin DSL for functional bean declaration.
It allows declaring beans as following:
beans {
bean<Foo>()
profile("bar") {
bean<Bar>("bar", scope = Scope.PROTOTYPE)
}
environment({ it.activeProfiles.contains("baz") }) {
bean { Baz(it.ref()) }
bean { Baz(it.ref("bar")) }
}
}
Advantages compared to Regular ApplicationContext API are:
- No exposure of low-level ApplicationContext API
- Focused DSL easier to read, but also easier to write with a fewer
entries in the auto-complete
- Declarative syntax instead of functions with verbs like registerBeans
while still allowing programmatic registration of beans if needed
- Such DSL is idiomatic in Kotlin
- No need to have an ApplicationContext instance to write how you
register your beans since beans { } DSL is conceptually a
Consumer<GenericApplicationContext>
This DSL effectively replaces ApplicationContext Kotlin extensions as
the recommended way to register beans in a functional way with Kotlin.
Issue: SPR-15755
This commit introduces an apply method to `WebClient.Builder`, allowing
users to make multiple changes to the builder in one consumer.
Issue: SPR-15743
The failures look like older failures possibly exposed by recent
changes in Reactor.
The one in ViewResolutionResultHandler is very old test error.
The one in Jackson2JsonDecoderTests is more recent but went unreported.
WriteBarrier acts as Subscription to both completionSubscriber and
writeSubscriber so the request method needs to be careful not to
pass on the request outside of readyToWrite or writeSubscriber checks.
ContentNegotiationManagerFactoryBean now provides an option to
explicitly set the strategies to use vs customizing a fixed
list of default strategies.
Issue: SPR-11114
This commit moves `toEntity(Class<T>)` and `toEntityList(Class<T>)`
from WebClient.ResponseSpec to ClientResponse. The main reason for doing
so is that the newly introduced `onStatus` method (see
2f9bd6e075) does not apply to these two
methods, and the result would be confusing. Also, `ClientResponse` and
`ResponseEntity` represent the same data: status code, headers, and a
body.
Issue: SPR-15724
This commit introduces a way to customize the WebClientExceptions, as
thrown by WebClient.ResponseSpec.bodyTo[Mono|Flux]. The first
customization will override the defaults, additional customizations are
simply tried in order.
Issue: SPR-15724
This commit changes `ServerRequest.attribute(String)`` to return
`Optional<Object>` instead of `Optional<T>`, where `T` was infered
from a type parameter.
Segment.value() now returns the actual original path segment value
including path parameters while semicolonContent() is removed.
valueDecoded() is renamed to valueToMatch() to reflect it is the value
for pattern matching which is not only decoded but also has path
parameters removed.
This commit makes the `uri` step of the WebTestClient optional, so that
users who have specified a base URL during WebClient config do not need
to provide an empty one (i.e. `url("")`).
Issue: SPR-15695
This commit makes the `uri` step of the WebClient optional, so that
users who have specified a base URL during WebClient config do not need
to provide an empty one (i.e. `url("")`).
The basic idea of this fix is that the HTTP method methods in WebClient
(`get`, `post`, etc.) should be able to "bypass" the uri stage, and skip
straight to defining headers, or even doing an exchange or retrieve
(i.e. call methods on `RequestHeaderSpec` or `RequestBodySpec`).
I have accomplished this by adding two new composed interfaces:
`RequestHeadersUriSpec` and `RequestBodyUriSpec`.
`RequestHeadersUriSpec` extends from the existing `UriSpec` and
`RequestHeaderSpec`, while `RequestBodyUriSpec` extends from `UriSpec`
and `RequestBodySpec`. These types are returned from the HTTP methods
(`get`, `post` etc). The `uri` methods on these types return a plain
`RequestHeaderSpec` and `RequestBodySpec` (i.e. types without the `uri`
methods), so that you can call `uri` once only.
Issue: SPR-15695
This commit introduces integration tests which verify that the
SpringExtension can be used in conjunction with JUnit Jupiter's
@ParameterizedTest support.
Explicitly pass the client-side JSR-356 WebSocketContainer to the
TomcatWebSocketClient to prevent the ContainerProvider from finding
the one from undertow-websockets-jsr through the ServiceLoader API.
This commit disables the "failOnServerError" feature on the
`HttpClientRequest`, as wrapped by ReactorClientHttpRequest. 5xx errors
are supposed to be dealt with in the WebClient, not in the lower-level
components.
Issue: SPR-15739
This commit introduces client-side request attributes, similar to those
found on the server-side. The attributes can be used, for instance, for
passing on request-specific information to a globally registered
ExchangeFilterFunction.
The client request builder, as well as WebClient.RequestHeadersSpec and
WebTestClient.RequestHeaderSpec, add methods for adding a single
attribute, as well as manipulating the entire attributes map.
The client request itself adds a accessor for the (immutable) attributes
map.
This commit also introduces a new variant of the basic authentication
filter in ExchangeFilterFunctions. This variant takes the username and
password from well-known attributes.
Issue: SPR-15691
Previously `UrlBasedCorsConfigurationSource` was relying on
`PathMatcher` implementations for matching incoming request lookup paths
with the configured path patterns for CORS configuration.
This commit replaces the use of `PathMatcher` with a `PathPatternParser`
that parses the string patterns into `PathPattenr` instances and allows
for faster matching against lookup paths.
Issue: SPR-15688
Note that WebFlux and WebFlux.fn can be both used at the same time
thanks to the handler mapping registration in `@EnableWebFlux`.
Fixing typos in the reference documentation for outdated Reactor
operators.
This commit changes ServerRequest.queryParams from returning a
List<String> given a String name, to returning a
MultiValueMap<String, String>, which gives more flexibility.
This commit uses the newly introduced `PathContainer` and `RequestPath`
support in the functional web framework. It exposes the path container
as property in `ServerRequest`, and uses that in the path-based
`RequestPredicates`.
Direct comparison of a pattern (as a String) to the path does not make
much sense now that we deal with URL encoding through PathContainer
which exposes (safely) decoded path segments.
Removing the PathPatternComparator also means we can keep patterns
pre-sorted instead of sorting them all the time. That probably offsets
any benefits from comparing to the lookup path for direct matches and
patterns are still sorted according to specificity.
The new PathContainer represent the path as a series of elements
including separators. This naturally represents leading/trailing
slashes and empty path segments which in turn makes it easier to match
in PathPattern as well as to reconstruct the path.
This commits extends nullability declarations to the field level, formalizing the interaction between methods and their underlying fields and therefore avoiding any nullability mismatch.
Issue: SPR-15720
This commit changes the release of data buffers from a finally block
into a `doFinally()` lambda on the returned `Flux<XMLEvent>` stream.
Issue: SPR-15707
This commit introduces the Jackson2Tokenizer as a replacement for the
JsonObjectDecoder. The latter was dropped because of its complexity, and
hard dependency on Netty's ByteBuf.
The new Jackson2Tokenizer leverages the new non-blocking JSON parser,
using it to parse the incoming data buffers into TokenBuffers, each
token buffer representing one JSON object. As with JsonObjectDecoder,
it also supports streaming individual JSON array elements.
Issue: SPR-14528
The cloneBuilder helps to avoid the issue in the comment of the ticket.
Rather than creating the WebClient to then obtain a fresh builder which
causes connector instantiation, we now use the cloneBuilder
Issue: SPR-15674
This commit adds a new `cloneBuilder()` method on `WebClient.Builder`;
we can now reuse the customizations of an existing builder without
sharing its state across several `WebClient` building code paths.
Issue: SPR-15690
This commit introduces 2 new public methods in HttpHeaders in order
to leverage Java 8 ZonedDateTime in addition to the existing long
(with GMT time zone implied) variants:
- ZonedDateTime getFirstZonedDateTime(String headerName)
- void setZonedDateTime(String headerName, ZonedDateTime date)
This commit also leverages Java 8 thread-safe DateTimeFormatter for
HttpHeader implementation instead of SimpleDateFormat. As a consequence
of the usage of DateTimeFormatter.RFC_1123_DATE_TIME, HTTP date header
serialization could change slightly for single digit days from for
example "Thu, 01 Jan 1970 00:00:00 GMT" to
"Thu, 1 Jan 1970 00:00:00 GMT".
Issue: SPR-15661
This new WebFilter implementation is designed to allow initial
CORS support when using WebFlux functional API. More high-level
API may be introduced later.
Issue: SPR-15567
This commit adds support for Void response body types in the WebClient,
both when using `exchange` with a response.bodyToMono(Void.class), as
well as using `retrieve` with `toEntity(Void.class)`.
Issue: SPR-15679
This commit replaces the WebClient.filter method with
WebClient.Builder.filter. The reason for this change is that filters
added via WebClient.filter would be applied in the opposite order of
their declaration, due to the compositional nature of the method,
combined with the immutable nature of the WebClient.
WebClient.Builder.filter does keep the order of the filters, as
registered.
Furthermore, this commit introduces a WebClient.mutate() method,
returning a WebClient.Builder. This method allow to add/remove filters
and other defaults from a given WebClient.
Issue: SPR-15657
Add WebClient.Builder.addFilter
Add Consumer-based headers and cookies methods to builders.
Add WebClient.mutate
This commit changes the `ExchangeStrategies` and `HandlerStrategies`
interfaces to consistently use the `CodecConfigurer` (and
sub-interfaces) for configuring codecs on the server and on the client.
Issue: SPR-15682
Supporting ScriptEngine#eval(String, Bindings) when no render function
is specified allows to support use cases where script templates are
simply evaluating a script expression with an even more simplified
configuration.
This improvement also makes it possible to use script engines that
do not implement Invocable.
Issue: SPR-15115
Static parse methods on PathSegmentContainer and PathSegment plus:
isEmpty() on PathSegmentContainer and PathSegment
isAbsolute() and hasTrailingSlash() on PathSegmentContainer
char[] alternative for valueDecoded() on PathSegment
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
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.
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.
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.
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
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
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
This commit updates HandlerAdapter#handle() to return HandlerResult
instead of Publisher<HandlerResult>. A new SimpleHandlerResultHandler
class has been introduced for handlers returning Publisher<Void>.
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.
Just enough for a test with an @ResponseBody method that accepts an
@RequestParam String arg and returning Publisher<String> or String.
See RequestMappingIntegrationTests.
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.
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 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.
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.
_Have something you'd like to contribute to the framework? We welcome pull
requests but ask that you carefully read this document first to understand how
best to submit them; what kind of changes are likely to be accepted; and what
to expect from the Spring team when evaluating your submission._
# Contributing to the Spring Framework
_Please refer back to this document as a checklist before issuing any pull
request; this will save time for everyone!_
First off, thank you for taking the time to contribute! :+1: :tada:
## Take Your First Steps
### Table of Contents
### Understand the basics
* [Code of Conduct](#code-of-conduct)
* [How to Contribute](#how-to-contribute)
* [Discuss](#discuss)
* [Create a Ticket](#create-a-ticket)
* [Ticket Lifecycle](#ticket-lifecycle)
* [Submit a Pull Request](#submit-a-pull-request)
* [Build from Source](#build-from-source)
* [Source Code Style](#source-code-style)
* [Reference Docs](#reference-docs)
Not sure what a pull request is, or how to submit one? Take a look at GitHub's
excellent [help documentation][] first.
### Code of Conduct
### Search Stack Overflow first; discuss if necessary
This project is governed by the [Spring Code of Conduct](CODE_OF_CONDUCT.adoc).
By participating you are expected to uphold this code.
Please report unacceptable behavior to spring-code-of-conduct@pivotal.io.
If you're unsure why something isn't working or wondering if there is a better
way of doing it please check on Stack Overflow first and if necessary start
a discussion. This is the official list of
[Spring project tags](https://spring.io/questions). In short the issue tracker
should be used to report issues and make feature requests.
### How to Contribute
### Search JIRA; create an issue if necessary
#### Discuss
Is there already an issue that addresses your concern? Do a bit of searching
in our [JIRA issue tracker][] to see if you can find something similar. If you
do not find something similar, please create a new JIRA issue before submitting
a pull request unless the change is truly trivial -- for example: typo fixes,
removing compiler warnings, etc.
If you have a question, check StackOverflow using
[this list of tags](https://spring.io/questions), organized by Spring project.
Find an existing discussion or start a new one if necessary.
### Discuss non-trivial contribution ideas with committers
If you suspect an issue, perform a search in the
[JIRA issue tracker](https://jira.spring.io/browse/SPR), using a few different keywords.
When you find related issues and discussions, prior or current, it helps you to learn and
it helps us to make a decision.
If you're considering anything more than correcting a typo or fixing a minor
bug, please discuss it on the [spring-framework-contrib][] mailing list before
submitting a pull request. We're happy to provide guidance, but please spend an
hour or two researching the subject on your own, including searching the mailing
list for prior discussions.
#### Create a Ticket
### Sign the Individual Contributor License Agreement (ICLA)
Reporting an issue or making a feature request is a great way to contribute. Your feedback
and the conversations that result from it provide a continuous flow of ideas.
If you have not previously done so, please fill out and submit the
[Spring ICLA form][]. You'll receive a token when this process is complete.
Keep track of this; you may be asked for it later!
Before you create a ticket, please take the time to [research first](#Discuss).
Note that emailing/postal mailing a signed copy is _not_ necessary. Submission
of the web form is all that is required.
If creating a ticket after a discussion on StackOverflow, please provide a self-sufficient description in the ticket, independent of the details on StackOverview. We understand this is extra work but the issue tracker is an important place of record for design discussions and decisions that can often be referenced long after the fix version, for example to revisit decisions, to understand the origin of a feature, and so on.
Once you've completed the web form, simply add the following in a comment on
your pull request:
When ready create a ticket in the [JIRA issue tracker](https://jira.spring.io/browse/SPR).
I have signed and agree to the terms of the Spring Individual Contributor
License Agreement.
#### Ticket Lifecycle
You do not need to include your token/id. Please add the above statement to all
future pull requests as well, simply so that the Spring Framework team knows
immediately that this process is complete.
When an issue is first created, it may not be assigned and will not have a fix version.
Within a day or two, the issue is assigned to a specific committer and the target
version is set to "Waiting for Triage". The committer will then review the issue, ask for
further information if needed, and based on the findings, the issue is either assigned a fix
version or rejected.
## Create a Branch
When a fix is ready, the issue is marked "Resolved" and may still be re-opened. Once a fix
is released, the issue is permanently "Closed". If necessary, you will need to create a new,
related ticket with a fresh description.
### Branch from `master`
#### Submit a Pull Request
Master currently represents work toward Spring Framework 4.0. Please submit
all pull requests there, even bug fixes and minor improvements. Backports to
`3.2.x` will be considered on a case-by-case basis.
You can contribute a source code change by submitting a pull request.
1. If you have not previously done so, please sign the
[Contributor License Agreement](https://cla.pivotal.io/sign/spring). You will also be reminded
automatically when you submit a pull request.
### Use short branch names
1. For all but the most trivial of contributions, please [create a ticket](#Create-a-Ticket).
The purpose of the ticket is to understand and discuss the underlying issue or feature.
We use the JIRA issue tracker as the preferred place of record for conversations and
conclusions. In that sense discussions directly under a PR are more implementation detail
oriented and transient in nature.
Branches used when submitting pull requests should preferably be named
according to JIRA issues, e.g. 'SPR-1234'. Otherwise, use succinct, lower-case,
dash (-) delimited names, such as 'fix-warnings', 'fix-typo', etc. In
[fork-and-edit][] cases, the GitHub default 'patch-1' is fine as well. This is
important, because branch names show up in the merge commits that result from
accepting pull requests and should be as expressive and concise as possible.
1. Always check out the `master` branch and submit pull requests against it
(for target version see [settings.gradle](settings.gradle)).
Backports to prior versions will be considered on a case-by-case basis and reflected as
the fix version in the issue tracker.
## Use Spring Framework Code Style
1. Use short branch names, preferably based on the JIRA issue (e.g. `SPR-1234`), or
otherwise using succinct, lower-case, dash (-) delimited names, such as `fix-warnings'.
The complete [Spring Framework Code Style][] reference is available on the wiki, but
here's a quick summary:
1. Choose the granularity of your commits consciously and squash commits that represent
multiple edits or corrections of the same logical change. See
[Rewriting History section of Pro Git](http://git-scm.com/book/en/Git-Tools-Rewriting-History)
for an overview of streamlining commit history.
### Mind the whitespace
1. Format commit messages using 55 characters for the subject line, 72 lines for the
description, followed by related issues, e.g. `Issues: SPR-1234, SPR-1235`.
See the
[Commit Guidelines section of Pro Git](http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines)
for best practices around commit messages and use `git log` to see some examples.
Please carefully follow the whitespace and formatting conventions already
present in the framework.
1. List the JIRA issue number in the PR description.
1. Tabs, not spaces
1. Unix (LF), not DOS (CRLF) line endings
1. Eliminate all trailing whitespace
1. Wrap Javadoc at 90 characters
1. Aim to wrap code at 90 characters, but favor readability over wrapping
1. Preserve existing formatting; i.e. do not reformat code for its own sake
1. Search the codebase using `git grep` and other tools to discover common
naming conventions, etc.
1. Latin-1 (ISO-8859-1) encoding for Java sources; use `native2ascii` to convert
if necessary
If accepted, your contribution may be heavily modified as needed prior to merging.
You will likely retain author attribution for your Git commits granted that the bulk of
your changes remain intact. You may also be asked to rework the submission.
If asked to make corrections, simply push the changes against the same branch, and your
pull request will be updated. In other words, you do not need to create a new pull request
when asked to make changes.
### Add Apache license header to all new classes
### Build from Source
```java
/*
* Copyright 2002-2015 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
See the [Build from Source](https://github.com/spring-projects/spring-framework/wiki/Build-from-Source)
wiki page for instructions on how to check out, build, and import the Spring Framework
source code into your IDE.
package...;
```
### Source Code Style
### Update Apache license header in modified files as necessary
The wiki pages
[Code Style](https://github.com/spring-projects/spring-framework/wiki/Code-Style) and
[IntelliJ IDEA Editor Settings](https://github.com/spring-projects/spring-framework/wiki/IntelliJ-IDEA-Editor-Settings)
defines the source file coding standards we use along with some IDEA editor settings we customize.
Always check the date range in the license header. For example, if you've
modified a file in 2015 whose header still reads:
### Reference Docs
```java
/*
*Copyright2002-2011theoriginalauthororauthors.
```
The reference documentation is in the [src/docs/asciidoc](src/docs/asciidoc) directory and, in
[Asciidoctor](http://asciidoctor.org/) format. For trivial changes, you may be able to browse,
edit source files, and submit directly from Github.
Then be sure to update it to 2015 accordingly:
When making changes locally, use `./gradlew asciidoctor` and then browse the result under
`build/asciidoc/html5/index.html`.
```java
/*
*Copyright2002-2015theoriginalauthororauthors.
```
### Use @since tags for newly-added public API types and methods
For example:
```java
/**
* ...
*
* @author First Last
* @since 4.2.3
* @see ...
*/
```
## Prepare Your Commit
### Submit JUnit test cases for all behavior changes
Search the codebase to find related tests and add additional `@Test` methods
as appropriate. It is also acceptable to submit test cases on a per JIRA issue
basis, for example:
```java
packageorg.springframework.beans.factory.support;
/**
* Unit tests for SPR-8954, in which a custom {@link InstantiationAwareBeanPostProcessor}
* forces the predicted type of a FactoryBean, effectively preventing retrieval of the
* bean from calls to #getBeansOfType(FactoryBean.class). The implementation of
* {@link AbstractBeanFactory#isFactoryBean(String, RootBeanDefinition)} now ensures
* that not only the predicted bean type is considered, but also the original bean
* definition's beanClass.
*
* @author Chris Beams
*/
publicclassSpr8954Tests{
@Test
publicvoidcornerSpr8954(){
// ...
}
}
```
### Squash commits
Use `git rebase --interactive --autosquash`, `git add --patch`, and other tools
to "squash" multiple commits into a single atomic commit. In addition to the man
pages for git, there are many resources online to help you understand how these
tools work. The [Rewriting History section of Pro Git][] provides a good overview.
### Use real name in git commits
Please configure git to use your real first and last name for any commits you
intend to submit as pull requests. For example, this is not acceptable:
Author: Nickname <user@mail.com>
Rather, please include your first and last name, properly capitalized, as
submitted against the Spring Individual Contributor License Agreement (ICLA):
Author: First Last <user@mail.com>
This helps ensure traceability against the ICLA and also goes a long way to
ensuring useful output from tools like `git shortlog` and others.
You can configure this via the account admin area in GitHub (useful for
fork-and-edit cases); _globally_ on your machine with
git config --global user.name "First Last"
git config --global user.email user@mail.com
or _locally_ for the `spring-framework` repository only by omitting the
'--global' flag:
cd spring-framework
git config user.name "First Last"
git config user.email user@mail.com
### Format commit messages
Please read and follow the [Commit Guidelines section of Pro Git][].
Most importantly, please format your commit messages in the following way
(adapted from the commit template in the link above):
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here
Issue: SPR-1234, SPR-1235
1. Use imperative statements in the subject line, e.g. "Fix broken Javadoc link".
1. Begin the subject line with a capitalized verb, e.g. "Add, Prune, Fix,
Introduce, Avoid, etc."
1. Do not end the subject line with a period.
1. Restrict the subject line to 50 characters or less if possible.
1. Wrap lines in the body at 72 characters or less.
1. Mention associated JIRA issue(s) at the end of the commit comment, prefixed
with "Issue: " as above.
1. In the body of the commit message, explain how things worked before this
commit, what has changed, and how things work now.
For examples of this style, issue a `git log --author=cbeams` in the
`spring-framework` git repository. For convenience, here are several such commits:
// Replace classpath entries with project dependencies (GRADLE-1116)
// http://issues.gradle.org/browse/GRADLE-1116
eclipse.classpath.file.whenMerged{classpath->
defregexp=/.*?\/([^\/]+)\/build\/[^\/]+\/(?:main|test)/// only match those that end in main or test (avoids removing necessary entries like build/classes/jaxb)
defregexp=/.*?\/([^\/]+)\/build\/([^\/]+\/)+(?:main|test)/// only match those that end in main or test (avoids removing necessary entries like build/classes/jaxb)
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