Expose RemoveJsonAttributesResponseBody YAML shortcut on MVC

[kalayciburak]

Summary

• Implement Shortcut.Type.LIST_TAIL_FLAG argument normalization (list fields + optional trailing boolean), matching WebFlux GATHER_LIST_TAIL_FLAG behavior
• Register FilterFunctions.removeJsonAttributesResponseBody so the documented MVC shortcut RemoveJsonAttributesResponseBody=id,color[,true] resolves
• The functional implementation already existed on AfterFilterFunctions; YAML/properties discovery only looks at FilterFunctions

Fixes #4240

Testing

• ./mvnw -pl spring-cloud-gateway-server-webmvc -am test -Dtest=NormalizedOperationMethodTests,AfterFilterFunctionsTests

[HDPark95]

Nice catch that the functional implementation already lives on AfterFilterFunctions and only the FilterFunctions discovery surface was missing — that lines up with the Unable to find operation interface ... symptom in #4240.

One thing worth calling out: this also activates Shortcut.Type.LIST_TAIL_FLAG, which was declared in the webmvc Shortcut.Type enum but had no branch in NormalizedOperationMethod#normalizeArgs (it previously fell through to default -> "Unknown Shortcut type"). removeJsonAttributesResponseBody looks like its first consumer in server-webmvc, so the new branch is effectively brand-new behavior rather than a pure re-wire.

My main suggestion is a test for the path #4240 actually breaks on. The three added tests only assert the output of normalizeArgs in isolation; none resolve the shortcut string through registration → invoke → the real filter, which is where the reported IllegalArgumentException originates. Could you add an end-to-end test that loads RemoveJsonAttributesResponseBody=id,color,true (and the no-flag form =id,color) as MVC route config and asserts the route builds without the exception and the filter actually strips the attributes from a response? GatewayMvcPropertiesBeanDefinitionRegistrarTests is a good pattern to follow (@SpringBootTest + properties + a live-route assertion).

This is worth doing specifically because LIST_TAIL_FLAG emits the list field as a raw List (new ArrayList<>(values)), whereas the sibling LIST branch emits a comma-delimited String and relies on downstream conversion to reach its varargs param. Binding a List straight into List<String> fieldList should work, but it is a value shape the current tests do not cover, so the integration test is what proves #4240 is genuinely closed.

Minor: the tail handling differs slightly from the reactive GATHER_LIST_TAIL_FLAG — when there is no boolean tail (or a null tail) the reactive version omits/nulls the flag field, while this always emits deleteRecursively=false. Defaulting the primitive boolean to false is arguably the safer choice for the MVC binder, so it reads as intentional; a one-line comment on normalizeListTailFlag noting the deliberate difference would keep someone from "aligning" it back later.

[kalayciburak]

yeah fair — added e2e properties routes that hit registration → invoke → live filter (no-flag + trailing true), plus a short note on why we always default the flag to false vs reactive.

pushed.