This commit adapts the error controller tests that need the request
to fail with a bind issue, and simulate the behavior of
ModelAttributeMethodProcessor.
As of Spring Framework 6.0.x, this processor no longer throws a
BindingException, but rather a MethodArgumentNotValidException and
the handing of BindException itself is deprecated.
This makes sure that those tests can smoothly be executed against
Spring Framework 6.2.x as throwing a BindingException now results
into an unresolved exception, and an internal server error rather than
the expected bad request.
See gh-39767
Update `AutoConfigurationSorter` so that `getClassesRequestedAfter()`
results are sorted to match the earlier name/order sorting. Prior to
this commit the order of items added via `@AutoConfigureAfter` was in
an undetermined order which could cause very subtle `@ConditionalOnBean`
bugs.
Thanks very much to Alexandre Baron for their help in diagnosing and
reproducing this issue.
Fixes gh-38904
The stream auto-configuration is tested in RabbitStreamConfigurationTests,
and excluding it prevents the creation of the "rabbitStreamEnvironment"
Environment bean, which delays the application context close by 1 second
because it has to wait for some Netty resources to gracefully shut down.
Closes gh-38750
When the filter is exposed as a bean (directly or through a
registration bean), it's picked up by the auto-configuration of
MockMvc. This causes a problem as MockMvc does not call init on a
filter before it's used and WebSocketUpgradeFilter fails with a
NullPointerException if its doFilter method is called when its init
method has not been called.
This commit reworks the WebSocket auto-configuration to use a
ServletContextInitalizer to register WebSocketUpgradeFilter rather
than a FilterRegistrationBean. This ensure that the filter is still
registered at the required position in the chain (last filter before
the servlet) while also preventing it from being registered with the
auto-configured MockMvc in tests.
Closes gh-37660
Update JMS listener concurrency configuration to set the same minimum
and maximum number of consumers when users specify only the minimum
using `spring.jms.listener.concurrency` property.
Prior to this commit, when using `spring.jms.listener.concurrency` to
set the minimum number of consumers without also specifying
`spring.jms.listener.max-concurrency` would result in effective
concurrency where the actual minimum number of consumers is always 1,
while the maximum number of consumers is the value of
`spring.jms.listener.concurrency`.
See gh-37180
