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.