17.0 does not work with Spring Boot 2.5.x

[marcust]

So I am currently looking for an upgrade path to GraphQL Java 17 with extended validation in a Spring Boot Application. It seems there is none, as the update to GraphQL Java 17 in extended validation came with an upgrade to Hibernate Validation (d779f85) to Hibernate Validator 7, which is not supported by Spring Boot (as it is not supported by Spring, see spring-projects/spring-boot#26705).

I tried some different combinations of downgraded/upgraded dependencies, but I am stuck. Am I missing something or can I not use the 17.0 version in a Spring Context?

[hantsy]

Hibernate Validator 7 used the new Jakarta EE 9 API level, which is planed in Spring 6.

Hope there is a variant for Jakarta EE 8, Hibernate Validator 6.2.1 + GraphQL 17.

[berngp]

Was there any reason to use Hibernate Validator 7.+ ?
Since Spring Boot is not planning to support Hibernate Validator 7 until its 3.x versions could we move back to the latest Hibernate Validator 6.+? Which is 6.2.0.Final at this time.

Ref. spring-projects/spring-boot#26705 (comment)

[hantsy]

As I know there are several Jakarta EE spec implementation projects which used Eclipse Transformer or Tomcat Jakarta EE migration to maintain the same source codes for Jakarta EE 8 and Jakarta EE 9(transformed by these tools).

@berngp I think the main difference between Hibernate Validator 6.x and 7.0 is they are referring to Jakarta EE 8 and 9 respectively.

[hantsy]

I created a simple EE 8 branch to downgrade it to Jakarta EE 8, I think it works well(the build is passed), I just downgraded the deps to Jakarta EE 8 API level and replace the jakarta. to javax. in the java source codes.

https://github.com/hantsy/graphql-java-extended-validation/tree/ee8

And I am trying to add another build profile to generate a copy for Jakarta EE 9(replace the javax. to jakarta. back in the source codes), but I am not a guru of Gradle, there are some issues in the copy/replace tasks in the generateSources phase, check the jakarta.build which can be triggered by a "jakarta" property in command line(-Pjakarta), please help me to overcome this barrier if you are a Gradle guru.

[berngp]

@hantsy I'm not sure having two artifacts is the best approach. Users will have to figure out which is the proper version they need to use according to the internals of the platform they choose. IMO if there is no strong need to move to Validator 7 then an approach to use Validator 6.x might be a simpler approach. So, I think the options are:

• [] Move back to 6.x
• [] Change the build to create multiple jars that are specific to EE 8 or EE 9.
• [] Keep using Validator 7 and shade the artifacts such that the EE namespaces are not exposed.

[hantsy]

If this project decided to upgrade to EE 9, it is better to maintain the source codes and add transformer task to generate a jar for EE 9, which is done by some Jakarta projects.

In the application frameworks world, only micronaunt 3 migrated to EE 9 APIs, most of current framework/tools are using EE 8 compatible APIs. But GraphQL Java related projects could be referred in these framework/tools projects, maintain two variants is reasonable, but this graphql-java-extended-validation project can be EE 8 only, and let the framework/tools projects do the EE9 transforming themselves.

[hantsy]

@marcust Add all deps to your project dependencies, it works, see: https://github.com/hantsy/spring-graphql-sample/blob/master/dgs-codegen/build.gradle#L26-L30

[WtfJoke]

Since Spring Boot is not planning to support Hibernate Validator 7 until its 3.x versions could we move back to the latest Hibernate Validator 6.+? Which is 6.2.0.Final at this time.

Ref. spring-projects/spring-boot#26705 (comment)

I also would favor to continue with hibernate validator 6.2.0.Final.

In our spring boot app (2.5.x) we stick to graphql-java-extended-validation:16.0.0 (which brings hibernate validator 6.1.6 which is not compatible with 6.2.0.Final) and override the version manually, see #50 (comment)

[marcust]

@marcust Add all deps to your project dependencies, it works, see: https://github.com/hantsy/spring-graphql-sample/blob/master/dgs-codegen/build.gradle#L26-L30

@hantsy this will only work until something in Spring tries to use Validation, because Spring will not be able to find the new SPI in the 7.x Validation and thus have a unsatisfied runtime dependency, see the issue linked in my original comment. If you throw in e.g. the spring boot validation starter that should trigger it.

[hantsy]

@marcust Try to use ResolutionStrategy to use different versions in the same build scripts.(But I have not tried this before)

See this discussion on stackoverflow: https://stackoverflow.com/questions/29374885/multiple-version-of-dependencies-in-gradle/29382370

[marcust]

@hantsy this will not work, because you can only have one version of an artifact on your classpath, and we are talking runtime dependencies here.

So if I start up your example with debug=true I see the following auto configuration snippet for Validation:

   ValidationAutoConfiguration:
      Did not match:
         - @ConditionalOnClass did not find required class 'javax.validation.executable.ExecutableValidator' (OnClassCondition)

assuming that I want to use any other Spring component that depends on Validation I have to make it find the correct conditional class by add the old validation api (that is what all of spring boot depends on)

   implementation 'javax.validation:validation-api:2.0.1.Final'

to the build.gradle file. This then gives me the following auto configuration report:

   ValidationAutoConfiguration:
      Did not match:
         - @ConditionalOnResource did not find resource 'classpath:META-INF/services/javax.validation.spi.ValidationProvider' (OnResourceCondition)
      Matched:
         - @ConditionalOnClass found required class 'javax.validation.executable.ExecutableValidator' (OnClassCondition)

So now I need the SPI, but I can not add the old validator version because we already have the new validator version:

    implementation 'org.hibernate.validator:hibernate-validator:7.0.1.Final'

in the build.gradle file.

Looking at the Validator jar file it only has the jakarta.validation.spi.ValidationProvider in the 7.0.1.Final jar file, whereas older Validator comes with the javax.validation.spi.ValidationProvider which is required by Spring Boot autoconfiguration.

So your example only works because you are not using the regular Spring Boot validation but only the Extended GraphQL Validation, which loads the validator not via Spring Boot but manually.

If you would add some bean validation (e.g. on your Entities) you would not be able to get that to work because of the dependency conflict.

Long story short, the only solution will be to have a version of this library that actually reverts back to validator 6.x

As I see @bbakerman did the update, is there any way we can get that done? Happy to help.

Or is there a compatibility layer between Jakarta Bean Validation 3.0 and JSR 380 that makes the 7.x Hibernate Validator work with Spring Boot? I guess that would be the only other option, but I guess there are too many changes (from a quick look at the changelog) to make that feasible.