Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Filters to be initialized when they're added to MockMvc #31362

Closed
wilkinsona opened this issue Oct 4, 2023 · 0 comments
Closed

Allow Filters to be initialized when they're added to MockMvc #31362

wilkinsona opened this issue Oct 4, 2023 · 0 comments
Assignees
Labels
in: test Issues in the test module in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@wilkinsona
Copy link
Member

Currently, when a Servlet Filter is added to MockMvc, its init(FilterConfig) method isn't called. This causes a problem for certain filters and doesn't align with the Servlet spec which requires init to be called before doFilter is called. While the caller that's adding the filter could call init, it's cumbersome as FilterConfig requires a ServletContext and there's no such context until the MockMvc instance has been built. It works with the following:

TestFilter testFilter = new TestFilter();
MockMvc mockMvc = MockMvcBuilders.standaloneSetup().addFilter(testFilter).build();
testFilter.init(new MockFilterConfig(mockMvc.getDispatcherServlet().getServletContext()));
mockMvc.perform(MockMvcRequestBuilders.get("/"));

I would like to see the builder streamline this by taking care of filter initialization. The existing methods for adding a filter could, perhaps, call init with an empty filter config that contains no init parameters. addFilter could then also be overloaded to allow init parameters to be passed in.

This suggestion is quite closely related to #27717 that proposes adding some support for registering filters for particular dispatcher types. Both would be very useful for Spring Boot's auto-configuring of MockMvc where any filters in the context are automatically added. Where those filters are represented by a FilterRegistrationBean we have information about dispatcher types and init parameters on hand that we could pass down into MockMvc if the API to do so was available.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Oct 4, 2023
@rstoyanchev rstoyanchev self-assigned this Oct 4, 2023
@rstoyanchev rstoyanchev added in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Oct 4, 2023
@rstoyanchev rstoyanchev added this to the 6.1.0-RC1 milestone Oct 4, 2023
@rstoyanchev rstoyanchev added the in: test Issues in the test module label Oct 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: test Issues in the test module in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

3 participants