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
If @AutoConfigureObservability is applied to a sliced test, it
auto-configures:
- An in-memory MeterRegistry
- A no-op Tracer
- An ObservationRegistry
Closes gh-38568
This auto-configuration ensures, if Micrometer Tracing is on the
classpath, that there is always a tracer. It backs off if there is
already a tracer, for example contributed by the Brave or the Otel
auto-configurations, which are run before.
See gh-38568
Following the changes in gh-37504, the reactive resource server
auto-configuration could enable WebFlux security in situations where
it was otherwise in active. This could then result in an application
failing to start as no authentication manager is available.
This commit updates the configurations that enable WebFlux security
so that they fully back off unless their related configurations are
active. Previously, only the configuration of the
SecurityWebFilterChain would back off. This has been expanded to
cover `@EnableWebFluxSecurity` as well. This has required splitting
the configuration classes up so that the condition evaluation order
can be controlled more precisely. We need to ensure that the JWT
decoder bean or the opaque token introspector bean has been defined
before evaluation of the conditions for `@EnableWebFluxSecurity`.
Without this control, the import through `@EnableWebFluxSecurity` in
one location where the conditions do not matchcan prevent a
successful import in another where they do.
Fixes gh-38713
1. remove unused imports
2. remove redundant semicolon
3. remove empty class body
4. remove redundant 'constructor' keyword
5. remove redundant 'Unit' return type
6. use non-null type if possible
See gh-38708
In gh-38154, we started handling ClosedByInterruptException. The
FileChannel was repaired by recreating it and then the exception was
rethrown. This allowed other threads to use the channel that had been
read by an interrupted thread while allowing that interruption to
continue.
This approach has proven to be insufficient as there are scenarios
where the read needs to succeed on the interrupted thread. This
commit updates the handling of ClosedByInterruptException so that
this is the case. The FileChannel is recreated as before but the
thread's interrupted flag is now cleared before retrying the read.
The flag is then reinstated so that any subsequent actions that
should fail due to the interruption will do so.
We could clear and reinstate the interrupted flag before the first
read, rather than catching ClosedByInterruptException. This approach
was rejected as it will have an impact on the performance of the
happy path where the thread hasn't been interrupted.
Fixes gh-38611
