EL-based validation message interpolation does not work when using spring-boot-starter-webflux

[wilkinsona]

spring-boot-starter-webflux does not include an EL implementation. This means that EL-based interpolation for validation messages does not work. For example, with an annotation like this:

@Size(min = 2, max = 14, message = "The item '${validatedValue}' must have {min} to {max} characters")
private String item;

The resulting message will look like this:

The item '${validatedValue}' must have 2 to 14 characters

Adding an EL implementation to the classpath changes the message to this:

The item 'a' must be between 2 and 14 characters long

[snicoll]

somewhat relates to #16593 ?

[wilkinsona]

Yes. Reviewing that PR is what made me realise it was missing – the proposed exclusion is unnecessary.

[wilkinsona]

I'm not sure how we should fix this. We generally assume that each embedded server starter will provide an EL implementation. That's true for Jetty, Tomcat, and Undertow, but not the case for Reactor Netty. I can think of two options:

1. Add an EL implementation to spring-boot-starter-reactor-netty
2. Add an EL implementation to spring-boot-starter-webflux

1 feels a bit odd as EL being provided by the embedded server is a Servlet convention. 2 is a bit problematic. If you exclude spring-boot-starter-reactor-netty to swap in Jetty, Tomcat, or Undertow, you'd end up with two EL implementation dependencies (each servlet container uses a different implementation).

Of the two, I think I'm leaning towards 2. Using WebFlux and swapping out Netty for a servlet container is an unusual thing to do. Requiring an extra exclusion to avoid two EL implementations being on the classpath (something that should be benign anyway) feels less bad than adding EL to the Reactor Netty starter.

[philwebb]

Hmm, I'd probably lean the other way just for consistency with the other starters. Is there much harm in always getting an EL implementation?

[wilkinsona]

No, not really. It just felt a bit odd. Irrespective of which starter we add it to, it'll end up on the classpath which is what we want. I'm convinced by the consistency argument so I'll add it to spring-boot-starter-reactor-netty. Thanks.