Spring-boot: Do not include the validation starter in web starters by default

[bclozel]

We've noticed that many applications are not using the validation features in web applications, while validator libraries on the classpath come with a cost.

We could do the following:

• remove the spring-boot-starter-validation dependency from spring-boot-starter-web and spring-boot-starter-webflux
• create a new spring-boot-starter-validation-web that brings in the validation dependencies without the tomcat-embed-el which is currently excluded by the web starters
• properly document that change in the release notes and the reference docs

[bclozel]

We'll do the following:

• remove the spring-boot-starter-validation from spring-boot-starter-web by default
• change spring-boot-starter-validation to use org.glassfish:jakarta.el instead of the current choice of default implementation
• update all the web servers starters to use that same el implementation for all

With this change, we don't need to add a new starter and we can consistently use the same el implementation.

[ofabricio]

I'm surprised to figure out not most projects are not using validations, because all my web apps use them. I had to include this new starter.

I'm wondering what is people using instead?

[bclozel]

The rationale behind this decision is not that most applications aren’t using validation, but rather that there is a significant amount of them and that the (startup and runtime) cost associated with the validation starter is far from negligible.

We usually try to strike the right balance between doing as much as possible with the developer’s intent and keeping setups efficient and lightweight. « Not all web applications should use validation and we want to optimize efficiency » is all that you should read into this decision.

[springframeworkguru]

This change caught me by surprise a little bit. In upgrading to 2.3.0, I added the validation API, but not the hibernate impl. My unit tests started covering validation started to fail. Without test coverage, might not have caught this.

Maybe consider failing startup if the API is present, and impl is not?

[bclozel]

@springframeworkguru Any reason why you're not using the spring-boot-starter-validation instead of bringing the dependencies manually in your build?

[springframeworkguru]

@bclozel - Just didn't know of it, until I saw this thread. I def will now though.

[abccbaandy]

+1 for add some warning or even fail to start, it's strange to silent skip valid check if valid stuff not work.

[Saljack]

I don't understand why it has been changed. If the people who don't want to use validation can exclude the spring-boot-starter-validation in spring-boot-starter-web and spring-boot-starter-webflux.

[wilkinsona]

@Saljack Please see this comment above for the reasoning behind the change.

[mykolap]

Decision about using jakarta-el instead of default el from tomcat was not the best choice for our project...
Now we got jsp compilation errors in many places
For example this function in jsp is ok for tomcat-el, but not ok for jakarta:
${eco:translate("JSON Pointer can be used for accessing body\'s parameters.")}
I had to exclude jakarta-el on project level.

[bclozel]

@mkopylec that's unfortunate. Did you raise an issue with the el library about this? Could you edit your comment linking to that issue for other community members? We chose the Jakarta implementation here as validation doesn't necessarily happen in a web application (so with a server) and pushing the Tomcat implementation for apps using another Servlet container didn't feel right.

[mykolap]

But jakarta-el is now used for compiling jsp, that doesn't look right too. It is present now as a dependency for tomcat starter, not only for validation starter

[mykolap]

See - it is compile dependency for tomcat starter, not only for validation starter...
https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-tomcat/2.3.2.RELEASE

[bclozel]

@mykolap if you've got a solution in mind, please submit a PR and we can reconsider this arrangement.

[mykolap]

I don't know how to resolve it properly...
If validation starter is not used - put tomcat-el as a compile dependency to tomcat starter looks good.
But if validation starter is used - we will have 2 libs with el, from jakarta and tomcat, and it should be resolved by excluding one of them...
It doesn't look nice... I will think about better solution, now I see the only way manual resolving, that's what I did in my project...