When auto-configuring MockMvc, add filters with their init parameters and dispatcher types

[wilkinsona]

There have been two recent enhancements in Framework 6.1:

• Allow Filters to be initialized when they're added to MockMvc spring-framework#31362
• Allow filters to be registered with MockMvc for particular dispatcher types spring-framework#27717

With these in place, we can now add filters to the auto-configured MockMvc instance using the dispatcher types and init parameters from their registration beans.

When implementing this we'll need to be careful that it doesn't result in multiple calls to the init method of a Filter instance.

[jeffbswope]

In 3.2.0-RC1 this -- and/or some related framework change? -- is causing MockMvc-based test regressions on our end with OncePerRequestFilter implementations.

• In 3.2.0-M3 I can see that our filters end up with null filterConfig so the filter ultimately uses {beanName}.FILTERED attribute to ensure it runs once per request.
• In 3.2.0-RC1 we are getting these filters with a filterConfig -- but all the filterConfig.getFilterName() values are empty string. So they all use .FILTERED attribute and only one will actually run.

May be related to change where before in MockMvc scenarios we end up with the filter class itself, but now we seem to end up with a MockMvcFilterDecorator even though we are not limiting dispatch or url patterns? Injection of that decorator leads to this change in boot because builder.addFilters(filter) will not wrap the filter whereas the .addFilter(...) overload being used in all cases now will always wrap with MockMvcFilterDecorator.

The core problem of all filters having the same non-null name links to the use of new MockFilterConfig(servletContext) in MockMvcFilterDecorator.initIfRequired since that results in filter name "" -- and that is in framework code on one of the issues you linked here: spring-projects/spring-framework#31362

[wilkinsona]

Thanks for trying out the RC, @jeffbswope. Can you please open a Framework issue for this as I think our hands are tied at the moment.

Some things that we could do on the Boot side if Framework allowed it:

• Provide a name for the filter
• Pass null for the init parameters rather than an empty map when there are none (the current lack of @Nullable means that we should do this although it looks like it would work).

Some things that Framework could do without any changes in Boot:

• Generate names for the filters
• Change MockMvcFilterDecorator.initIfRequired(ServletContext) to treat an empty initParams the same as null

Ultimately, I think the best fix will be that Boot provides a name for the filter but we can sort something out on the Framework side and then open an issue for the Boot side of things.

[rstoyanchev]

I added a name parameter to the addFilter method with the initParams array. Note that the name is nullable but a filter name should be passed in or otherwise MockFilterConfig defaults an empty String. In other words, for initialization with FilterConfig there needs to be some name.

[wilkinsona]

Thanks, Rossen.

I've opened #38001 to fix this in Boot by making use of the new name parameter.