Affects: 5.3.3
When I run a test using WebTestClient.bindToController(myController).build();
I also have to call RequestContextHolder.setRequestAttributes(attributes, true);
in order to have a request scope available for my application to use. This should be done automatically.
Comment From: rstoyanchev
RequestContextHolder sets up a ThreadLocal
but in a WebFlux application, the controller may not be invoked in the same thread. Therefore it doesn't make sense to do this automatically.
Comment From: mjaggard
That's true when you're testing a Webflux application but I'm not - I'm testing a traditional application.
Comment From: rstoyanchev
@mjaggard, I gather this is through MockMvcWebTestClient
in which case MockMvc
uses the DispatcherServlet
and that should be taking care of setting the RequestContextHolder
. If you could, please provide some more detail on how to reproduce the issue.
Comment From: mjaggard
No I don't think it was MockMvcWebTestClient. My test is doing
webClient = WebTestClient.bindToController(controller)
.configureClient()
.build();
in the setup and then the actual tests do things like this
webClient.get()
.uri("/pathToTheEndpointUnderTest")
.exchange()
.expectStatus()
.isOk()
.expectBody()
.jsonPath("primaryAction.label")
.isEqualTo("Edit Account");
Having said that, I don't use the request scope (@Scope("request")
) any more so this fix is no longer required for my use case.
Comment From: mjaggard
Ah, I see. I should have used MockMvcWebTestClient.bindToController
but I used WebTestClient.bindToController
which does the same thing but with different code in the background to support non-reactive and reactive controllers.
That API design is confusing at best because it works using the reactive version on non-reactive controllers except for RequestContextHolder
not being populated.
Comment From: rstoyanchev
Yes, WebTestClient
tests a WebFlux or a live backend. MockMvcWebClient
is layer on top to test with MockMvc as the backend.
I don't see anything we can change here. RequestContextHolder
doesn't apply for WebFlux, and there are many more differences between Spring MVC and WebFlux even if the programming model is very similar.