This commit extracts a Class.getName() invocation from String
concatenation in AbstractMonitoringInterceptor to avoid an issue
related to profile pollution.
Closes gh-25324
Prior to this commit, UriComponentsBuilder.fromHttpUrl() threw an
IllegalArgumentException if the provided URL contained a fragment.
This commit aligns the implementation of fromHttpUrl() with that of
fromUriString(), by parsing a fragment and storing it in the builder.
Closes gh-25300
The following was reported after the change and is related to it:
https://github.com/reactor/reactor-netty/issues/1170. An HTTP HEAD with the body
not consumed. Connection is disposed and closed leading to subsequent request to
fail. Adding toBodilessEntity() helps.
This change does not close the connection but rather drains the body which does
not impact subsequent re-use of the connection. This however may compete with a
late subscriber actually attempting to read the response. At that point there is
little choice but to raise an ISE with a more specific description.
See gh-25216
This commit ensures that when mutating `ServerHttpRequest` instances,
the original contextPath information is copied to the request being
built.
Note that mutation on the `contextPath(String)` or `path(String)` should
be reflected to the other. (See their Javadoc for more information).
Fixes gh-25279
With this commit it is no longer assumed that all charset names in the
JsonEncoding can be resolved by Charset.forName. Instead, we store the
charset name itself, rather than the Charset object.
Prior to this commit, the `SslInfo` would be missing for WebFlux apps
when deployed on Reactor Netty with http/2.
This commit ensures that the request adapter checks the current channel
and the parent channel for the presence of the `SslHander`.
In the case of http/2, the `SslHander` is tied to the parent channel.
Fixes gh-25278
This commit makes sure that Jackson-based message converters and
decoders can deal with non-unicode input. It does so by reading
non-unicode input messages with a InputStreamReader.
This commit also adds additional tests forthe canRead/canWrite methods
on both codecs and message converters.
Closes: gh-25247
Prior to this commit, a change to Javadoc in any class in spring-core
would result in ALL tests in the entire test suite being re-run via the
Gradle build.
Thanks to a tip from @melix, this commit aims to ensure that the
spring-core JAR is "reproducible".
Setting path variables (and making sure they are available in a
HandlerFunction) is more convenient with MockServerRequest than
having to set attributes in MockServerWebExchange.
This commit removes MockServerRequest's deprecation.
Closes gh-25087
The AspectJPrecedenceComparator was designed to mimic the precedence
order enforced by the AspectJ compiler with regard to multiple 'after'
methods defined within the same aspect whose pointcuts match the same
joinpoint. Specifically, if an aspect declares multiple @After,
@AfterReturning, or @AfterThrowing advice methods whose pointcuts match
the same joinpoint, such 'after' advice methods should be invoked in
the reverse order in which they are declared in the source code.
When the AspectJPrecedenceComparator was introduced in Spring Framework
2.0, it achieved its goal of mimicking the AspectJ compiler since the
JDK at that time (i.e., Java 5) ensured that an invocation of
Class#geDeclaredMethods() returned an array of methods that matched the
order of declaration in the source code. However, Java 7 removed this
guarantee. Consequently, in Java 7 or higher,
AspectJPrecedenceComparator no longer works as it is documented or as
it was designed when sorting advice methods in a single @Aspect class.
Note, however, that AspectJPrecedenceComparator continues to work as
documented and designed when sorting advice configured via the
<aop:aspect> XML namespace element.
PR gh-24673 highlights a use case where AspectJPrecedenceComparator
fails to assign the highest precedence to an @After advice method
declared last in the source code. Note that an @After advice method
with a precedence higher than @AfterReturning and @AfterThrowing advice
methods in the same aspect will effectively be invoked last due to the
try-finally implementation in AspectJAfterAdvice.invoke() which invokes
proceed() in the try-block and invokeAdviceMethod() in the
finally-block.
Since Spring cannot reliably determine the source code declaration
order of annotated advice methods without using ASM to analyze the byte
code, this commit introduces reliable invocation order for advice
methods declared within a single @Aspect. Specifically, the
getAdvisors(...) method in ReflectiveAspectJAdvisorFactory now hard
codes the declarationOrderInAspect to `0` instead of using the index of
the current advice method. This is necessary since the index no longer
has any correlation to the method declaration order in the source code.
The result is that all advice methods discovered via reflection will
now be sorted only according to the precedence rules defined in the
ReflectiveAspectJAdvisorFactory.METHOD_COMPARATOR. Specifically, advice
methods within a single @Aspect will be sorted in the following order
(with @After advice methods effectively invoked after @AfterReturning
and @AfterThrowing advice methods): @Around, @Before, @After,
@AfterReturning, @AfterThrowing.
The modified assertions in AspectJAutoProxyAdviceOrderIntegrationTests
demonstrate the concrete effects of this change.
Closes gh-25186
Sam Brannen
Сергей Цыпанов
Juergen Hoeller
Rossen Stoyanchev
DK Lee
Brian Clozel
Arjen Poutsma
wonwoo
Spring Buildmaster